Re: Hot standby, race condition between recovery snapshot and commit

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby, race condition between recovery snapshot and commit
Date: 2009-11-15 12:32:31
Message-ID: 4AFFF4DF.7070203@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-11-15 12:36:04 Re: commitfest patch move unavailable
Previous Message Hitoshi Harada 2009-11-15 11:42:53 Re: Aggregate ORDER BY patch