Re: Sync Rep and shutdown Re: Sync Rep v19 - Mailing list pgsql-hackers

On Wed, Mar 16, 2011 at 6:23 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 1. If a die interrupt is received (pg_terminate_backend or fast
>> shutdown), then terminate the sync rep wait and arrange for the
>> connection to be closed without acknowledging the commit (but do send
>> a warning message back).  The commit still happened, though, so other
>> transactions will see its effects.  This is unavoidable unless we're
>> willing to either ignore attempts to terminate a backend waiting for
>> sync rep, or panic the system when it happens, and I don't think
>> either of those is appropriate.
>
> Is it possible to force the standby out here, so that logs show that
> there was something going on wrt replication?

That's an interesting idea, but I think it might be too much spooky
action at a distance.  I think we should look at getting Fujii Masao's
replication_timeout patch committed; that seems like the right way to
kick out unresponsive standbys.  Another problem with doing it here is
that any ERROR will turn into a PANIC, which rules out doing anything
very complicated.  Also note that we can (and do) log a WARNING, which
I think answers your concern about having something in the logs wrt
replication.

A further point is that even if we could kick out the standby, it'd
presumably reconnect after the usual 2 s interval, so it doesn't seem
like it really accomplishes much.  We can't just unilaterally decide
that it is no longer allowed to be a sync standby ever again; that's
controlled by postgresql.conf.

I think the most important part of all this is that it is logged.
Anyone who is running synchronous replication should also be doing
careful monitoring; if not, shame on them, because if your data is
important enough that you need synchronous replication, it's surely
important enough to watch the logs.  If you don't, all sorts of bad
things can happen to your data (either related to sync rep, or
otherwise) and you'll have no idea until it's far too late.

>> 2. If a query cancel interrupt is received (pg_cancel_backend or ^C),
>> then cancel the sync rep wait and issue a warning before acknowledging
>> the commit.  Again, the alternative is to either ignore the cancel or
>> panic, neither of which I believe to be what users will want.
>
> Or force the standby to disconnect.
>
> In both those cases what we have is a situation were either we can't
> satisfy the user request or we can't continue to offer sync rep.  You're
> saying that we have to satisfy the user's query, so I say kick off sync
> rep or it does not make any sense.

Same considerations here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company