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

[Tatsuo Ishii]

>> 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?

Shut out all users from pgpool then execute DROP DATABASE?

>> 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?

Yes. If pgpool detects in consistency inconsistency of DML, pgpool
process exits itself, thus connections to PostgreSQL is
disconnected. PostgreSQL automatically rollbacks transaction if
connection from frontend (pgpool) is disconnected.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp