<div class="im" style="font-family:arial,sans-serif;font-size:13px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

For DMLs such as INSERT/UPDATE/DELETE which are allowed to execute in<br>a transaction block, pgpool automatically start an explicit<br>transaction so that it can be rolled back by exiting pgpool child when<br>command results from each node do not agree.<br>

<br>Unfortunately since DROP DATABASE cannot execute in a transaction<br>block and pgpool does not start an explicit transaction, DROP DATABASE<br>may causes inconsistency among backends. I don&#39;t think checking DROP<br>

DATABASE can be executed beforehand is easy: there&#39;s always a window<br>between at the time check and actual execution of DROP DATABASE.<br><br></blockquote><div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">

So is there any recommended way to execute such statements that PGPool can&#39;t handle that well?</div><div class="im" style="font-family:arial,sans-serif;font-size:13px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

BTW If you dislike degrading you can set:<br><br>replication_stop_on_mismatch = off<br></blockquote><div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">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? </div>