Re: Hot standby, race condition between recovery snapshot and commit - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Hot standby, race condition between recovery snapshot and commit
Date
Msg-id 4AFFF4DF.7070203@enterprisedb.com
Whole thread Raw
In response to Re: Hot standby, race condition between recovery snapshot and commit  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Hot standby, race condition between recovery snapshot and commit
Re: Hot standby, race condition between recovery snapshot and commit
List pgsql-hackers
Simon Riggs wrote:
> On Sat, 2009-11-14 at 14:59 +0200, Heikki Linnakangas wrote:
>> I can't see any obvious way around that. 
> 
> Huh? We're only doing this strict locking approach because you insisted
> that the looser approach was not acceptable.

Take it easy, Simon. By obvious, I meant "trivial" or "easy".  I believe
you're referring to this
(http://archives.postgresql.org/message-id/4A8CE561.4000302@enterprisedb.com):
> If there's a way, I would prefer a solution where the RunningXacts
> snapshot represents the situation the moment it appears in WAL, not some
> moment before it. It makes the logic easier to understand.

or did we have further discussion on that since?

> Have you forgotten that
> discussion so completely that you can't even remember the existence of
> other options? 

I do remember that. I've been thinking about the looser approach a lot
since yesterday.

So, if we drop the notion that the running-xacts record represents the
situation at the exact moment it appears in WAL, what do we have to
change? Creating the running-xacts snapshot becomes easier, but when we
replay it, we must take the snapshot with a grain of salt.

1. the snapshot can contain xids that have already finished (= we've
already seen the commit/abort record)
2. the snapshot can lack xids belonging to transactions that have just
started, between the window when the running-xacts snapshot is taken in
the master and it's written to WAL.

Problem 1 is quite easy to handle: just check every xid in clog. If it's
marked there as finished already, it can be ignored.

For problem 2, if a transaction hasn't written any WAL yet, we might as
well treat it as not-yet-started in the standby, so we're concerned
about transactions that have written a WAL record between when the
running-xacts snapshot was taken and written to WAL. Assuming the
snapshot was taken after the REDO pointer of the checkpoint record, the
standby has seen the WAL record and therefore has all the information it
needs. Currently, the standby doesn't add xids to known-assigned list
until it sees the running-xacts record, but we could change that.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Hitoshi Harada
Date:
Subject: Re: Aggregate ORDER BY patch
Next
From: Robert Haas
Date:
Subject: Re: commitfest patch move unavailable