Horton

Re: Standalone synchronous master

Florian G. Pflug <fgp@phlo.org>

View thread View on postgr.es
From: Florian Pflug <fgp@phlo.org>
To: Andres Freund <andres@2ndquadrant.com>
Cc: "Joshua D. Drake" <jd@commandprompt.com>, Stephen Frost <sfrost@snowman.net>, Adrian Klaver <adrian.klaver@gmail.com>, Josh Berkus <josh@agliodbs.com>, Bruce Momjian <bruce@momjian.us>, Amit Kapila <amit.kapila16@gmail.com>, Hannu Krosing <hannu@2ndquadrant.com>, MauMau <maumau307@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kevin Grittner <kgrittn@ymail.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, Simon Riggs <simon@2ndquadrant.com>, Rajeev rastogi <rajeev.rastogi@huawei.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-01-12T15:59:21Z
Lists: pgsql-hackers 
On Jan11, 2014, at 18:53 , Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-01-11 18:28:31 +0100, Florian Pflug wrote:
>> Hm, I was about to suggest that you can set statement_timeout before
>> doing COMMIT to limit the amount of time you want to wait for the
>> standby to respond. Interestingly, however, that doesn't seem to work,
>> which is weird, since AFAICS statement_timeout simply generates a
>> query cancel requester after the timeout has elapsed, and cancelling
>> the COMMIT with Ctrl-C in psql *does* work.
> 
> I think that'd be a pretty bad API since you won't know whether the
> commit failed or succeeded but replication timed out. There very well
> might have been longrunning constraint triggers or such taking a long
> time.

You could still distinguish these cases because the COMMIT would succeed
with a WARNING if the timeout elapses while waiting for the standby, just
as it does for query cancellations already.

I'm not saying that this is a great API, though - I brought it up only
because I accepting cancellation requests but ignoring timeouts seems
a bit inconsistent to me.

best regards,
Florian Pflug