On Sun, Apr 29, 2012 at 4:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@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
