On Fri, Apr 8, 2011 at 2:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> There is an open item for synchronous replication and smart shutdown,
>> with a link to here:
>> http://archives.postgresql.org/pgsql-hackers/2011-03/msg01391.php
>
>> There are a couple of plausible ways to proceed here:
>
>> 1. Do nothing.
>
>> 2. When a smart shutdown is initiated, shut off synchronous
>> replication.
>
>> 3. Accept new replication connections even when the system is
>> undergoing a smart shutdown.
>
> I agree that #3 is impractical and #2 is a bad idea, which seems to
> leave us with #1 (unless anyone has a #4)? This is probably just
> something we should figure is going to be one of the rough edges
> in the first release of sync rep.
That's kind of where my mind was headed too, although I was (probably
vainly) hoping for a better option.
> A #4 idea did just come to mind: once we realize that there are no
> working replication connections, automatically do a fast shutdown
> instead, ie, forcibly roll back those transactions that are never
> gonna complete. Or at least have the postmaster bleat about it.
> But I'm not sure what it'd take to code that, and am also unsure
> that it's something to undertake at this stage of the cycle.
Well, you certainly can't do that. By the time a transaction is
waiting for sync rep, it's too late to roll back; the commit record is
already, and necessarily, on disk. But in theory we could notice that
all of the remaining backends are waiting for sync rep, and switch to
a fast shutdown.
Several people have suggested refinements for smart shutdown in
general, such as switching to fast shutdown after a certain number of
seconds, or having backends exit at the end of the current transaction
(or immediately if idle). Such things would both make this problem
less irksome and increase the overall utility of smart shutdown
tremendously. So maybe it's not worth expending too much effort on it
right now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company