[Pgpool-general] Zimbra Detected SpamPgPool replication or Slony
Pascal Cohen
pcohen at wimba.com
Mon Nov 26 08:00:30 UTC 2007
Tatsuo Ishii wrote:
>>> Can that situation occurs also with PgPool replication like:
>>> PgPool sends update of A in M .
>>> First request on A goes on M.
>>> Second request on A goes to S.
>>> PgPool sends update to S.
>>>
>
> This could happen too, though the window is very narrow comparing with
> Slony-I. As of pgpool-II 2.0, any query is executed as an explicit
> transaction. Let's say you have a master and two slaves and you send an
> update query to pgpool-II.
>
>
Thanks, it was almost a theoretical question - but if it can happen, it
will happen in Production the day you are not expecting it ;)
> Also note that in pgpool, if you send an update then a select to
> retrieve the result in a *same session*, it's guaranteed that the
> select returns the result of update since the update and select will
> be executed on a same PostgreSQL node even if the load balanace option
> is enabled.
>
I had noticed that.
Does the lock mechanism change anything to my question ?
In fact I made the following tests with and without the lock:
* pgpool distributing the load on 3 machines A,B,C defined in that order
in the list.
* I create a table with an id as primary key and a string column.
*Through several psql connections via pgpool I update the DB and add
some rows.
* Then I add manually in B server a line with id let's say 5. When then
I reconnect the psql client and try to add a row with id 5, it fails as
expected and detecting data inconsistency, it removes A.
* When I do not set any lock, I get in fact A with the new row with
id=5, the second one with previous row and C with no row.
* When I use the lock A and C remain consistent with no new row while B
has its previous row.
My idea is to keep the DB consistency among the three databases (a kind
of two-phase commit). And I just added that row to check the behavior on
the three database when an error might occur on a given DB.
It is like with no-lock I can't guarantee the DB consistency and that
with lock I can.
Am I right ?
And with the lock, can the update be "accessed" on all the tables only
after all the DB have comited their update ?
Thanks for your answer and also thank you for PgPool which is a very
nice tool.
Pascal
More information about the Pgpool-general
mailing list