Re: Standalone synchronous master
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Florian Pflug <fgp@phlo.org>
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-11T17:53:28Z
Lists: pgsql-hackers
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. So it really would need a separate GUC. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services