From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Synchronization levels in SR |
Date: | 2010-05-26 22:23:05 |
Message-ID: | 1274912585.6203.3661.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2010-05-27 at 00:21 +0300, Heikki Linnakangas wrote:
> On 26/05/10 23:31, Dimitri Fontaine wrote:
> > d. choice of commit or rollback at timeout
>
> Rollback is not an option. There is no going back after the commit
> record has been flushed to disk or sent to a standby.
There's definitely no going back after the xid has been removed from
procarray because other transactions will then depend upon the final
state. Currently we PANIC if we abort after we've marked clog, though
that happens after XLogFlush(), which is where we're planning to wait
for synch rep. If we abort after having written a commit record to disk
we can still successfully generate an abort record as well. (Luckily, I
note HS does actually cope with that. Phew!)
So actually, an abort is a reasonable possibility, though I know it
doesn't sound like it could be at first thought.
> The choice is to either commit anyway after the timeout, or wait forever.
Hmm, wait forever. What happens if we try to shutdown fast while there
is a transaction that is waiting forever? Is that then a commit, even
though it never made it to the standby? How would we know it was safe to
switchover or not? Hmm.
Oracle offers options of COMMIT | SHUTDOWN in this case.
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-05-26 22:34:59 | Re: Keepalive for max_standby_delay |
Previous Message | Heikki Linnakangas | 2010-05-26 22:21:33 | pgsql: In walsender, don't sleep if there's outstanding WAL waiting to |