[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slony1-general
Subject:    Re: [Slony1-general] slony replication lag and pgpool
From:       Christian Storm <storm () iparadigms ! com>
Date:       2007-01-19 22:00:00
Message-ID: BCF254E0-8F72-4201-9CA5-C48B2DD6BC58 () iparadigms ! com
[Download RAW message or body]


On Jan 19, 2007, at 5:55 AM, Brad Nicholson wrote:

> You should raise your questions with the folks on the pgpool list.
> Slony people probably aren't the right audience to discuss pgpool mods
> with.  A couple quick points though -

Agreed.  I threw it against this list just in case someone had some  
non-pgpool insite into
this issue.

My apologies for contributing a little bit of noise on the list.

>> Otherwise, they go
>> to the slave.  As I'm sure you know, this can cause problems when
>> SELECT queries are run against the slave and the data hasn't  
>> arrived yet
>> due to the replication lag.
>
> That problem doesn't exist if you put your queries inside a  
> transaction.
> They will never go to a subscriber.

This is true but once you commit they will instantly start going to  
the subscriber.  That is the problem.
Bundling the queries into one transaction isn't an option.  The  
typical scenario for web apps where this
is a problem is when form data is inserted into the database within a  
transaction and then a user is redirected
to another page which queries the database looking for that new  
data.  This is where the replication lag
will bite you.
_______________________________________________
Slony1-general mailing list
Slony1-general@gborg.postgresql.org
http://gborg.postgresql.org/mailman/listinfo/slony1-general
[prev in list] [next in list] [prev in thread] [next in thread]