On Sun, Apr 29, 2012 at 4:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Eisentraut <pete...@gmx.net> writes: >> In any case, if either the existing session of the TM is cut or it >> cannot create a new connection, it will, after some time, have to give >> up roll back the prepared transactions on the other servers. So some >> kind of setting to not shut down if there are prepared transactions >> pending could be useful. But this could probably be a separate GUC >> setting or two instead of a shutdown mode (or two) of its own. > > This argument still seems pretty bogus. The *entire* point of a TM > is to cope with crashes of individual databases under its management. > The proposed setting seems to amount to a "please don't crash" GUC, > which is silly on its face, and does not actually make the TM's life > any easier anyway.
You are right that the TM can cope with aborted transactions, but that doesn't mean we should force it to have to do that. If we can wait for commit then we should do so. I think we only need one new mode, "shutdown when transactions are finished" should only shutdown when all types of transaction are complete. For people that don't use prepared transactions the difference is irrelevant. For people that do use prepared transactions, I can't imagine they would want a new setting that ends with aborted transactions, since that isn't any different to a fast shutdown. If that hangs waiting for TM that has gone away, then you can issue shutdown fast. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers