[pgpool-general: 1248] Re: Dropping template1 through PGPool not possible

Maik Kulbe maik.kulbe+pgpool at gmail.com
Fri Dec 7 18:37:05 JST 2012


>
> For DMLs such as INSERT/UPDATE/DELETE which are allowed to execute in
> a transaction block, pgpool automatically start an explicit
> transaction so that it can be rolled back by exiting pgpool child when
> command results from each node do not agree.
>
> Unfortunately since DROP DATABASE cannot execute in a transaction
> block and pgpool does not start an explicit transaction, DROP DATABASE
> may causes inconsistency among backends. I don't think checking DROP
> DATABASE can be executed beforehand is easy: there's always a window
> between at the time check and actual execution of DROP DATABASE.
>
>
So is there any recommended way to execute such statements that PGPool
can't handle that well?


> BTW If you dislike degrading you can set:
>
> replication_stop_on_mismatch = off
>

That sounds a little bit risky. I have reproduced several problems in the
last days, like queries that, when executed simultaniously, make problems
once in a while and produce different states on the machines. Or would that
be handled by the transaction rollback mechanism you mentioned?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20121207/9a513fb0/attachment.html>


More information about the pgpool-general mailing list