Re: smart shutdown at end of transaction (was: Default mode for shutdown)

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)
Date: 2012-04-27 20:30:10
Message-ID: 201204272230.10692.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aakash Goel 2012-04-27 20:49:37 Re: xReader, double-effort (was: Temporary tables under hot standby)
Previous Message Peter Eisentraut 2012-04-27 20:24:16 Re: plpython crash (PG 92)