Re: smart shutdown at end of transaction (was: Default mode for shutdown) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: smart shutdown at end of transaction (was: Default mode for shutdown)
Date
Msg-id 201204272230.10692.andres@anarazel.de
Whole thread Raw
In response to Re: smart shutdown at end of transaction (was: Default mode for shutdown)  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: smart shutdown at end of transaction (was: Default mode for shutdown)  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Friday, April 27, 2012 10:17:59 PM Peter Eisentraut wrote:
> On fre, 2012-04-27 at 20:39 +0200, Andres Freund wrote:
> > I think the current smart mode is rather useful. There is quite some
> > stuff that you cannot do inside a transaction - or it doesn't make
> > sense - which still needs to shutdown gracefully. E.g. transaction
> > managers.
> Could you elaborate on that?  What would happen to the transaction
> manager if you terminate any idle, not-in-a-transaction database backend
> sessions it has established?
In the few cases where I investigated it TMs don't use transactions themselves 
(which I think is correct, they don't need them), so terminating any idle 
session - which the TM would appear as, as its not using txns - would leave 
prepared transactions in a limbo state till the database is up again, instead 
of waiting till all prepared transactions are either aborted or committed. It 
may also choose to coordinate to abort all transactions, but all that is hard 
if the database shuts you out.
I actually also have co-maintained other software where some processes have an 
idle connection open on which some shutdown stuff will happen. Obviously all 
those will need to handle the case where the connection was aborted, but that 
may result in suboptimal behaviour. Requiring such processes to keep open a 
transaction doesn't seem to be a good design choice in the pg world.

Andres


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: plpython crash (PG 92)
Next
From: Aakash Goel
Date:
Subject: Re: xReader, double-effort (was: Temporary tables under hot standby)