> Suppose table A gets updated on the master at time 00:00. Until 00:03
> pgpool needs to send all queries regarding A to the master only. My
> question is, how can pgpool know a query is related to A?

Well, I'm a little late to head off tangental discussion about this, but ....

The systems where I've implemented something similar are for web applications.  
In the case of the web app, you don't care if a most users see data which is 
2 seconds out of date; with caching and whatnot, it's often much more than 

The one case where it's not permissable for a user to see "old" data is the 
case where the user is updating the data.   Namely:

(1) 00:00 User A updates "My Profile"
(2) 00:01 "My Profile" UPDATE finishes executing.
(3) 00:02  User A sees "My Profile" re-displayed
(6) 00:04  "My Profile":UserA cascades to the last Slave server

So in an application like the above, it would be a real problem if User A were 
to get switched over to a slave server immediately after the update; she 
would see the old data, assume that her update was not saved, and update 
again.  Or send angry e-mails to [EMAIL PROTECTED]   

However, it makes no difference what User B sees:

(1) 00:00 User A updates "My Profile"v1                 Master
(2) 00:01 "My Profile" UPDATE finishes executing.       Master
(3) 00:02  User A sees "My Profile"v2 displayed         Master
(4) 00:02  User B requests "MyProfile":UserA            Slave2
(5) 00:03  User B sees "My Profile"v1                           Slave2
(6) 00:04  "My Profile"v2 cascades to the last Slave server  Slave2

If the web application is structured properly, the fact that UserB is seeing 
UserA's information which is 2 seconds old is not a problem (though it might 
be for web auctions, where it could result in race conditions.   Consider 
memcached as a helper).   This means that pgPool only needs to monitor 
"update switching" by *connection* not by *table*.

Make sense?

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to