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

On Sun, 2009-11-15 at 14:43 +0200, Heikki Linnakangas wrote:

> This isn't absolutely necessary for the first version, but it's
> something to keep in mind...

Do I take that as agreement to the phased plan?

> In general, I'd like to remove as many as possible of those cases
> where the standby starts up, and can't open up for connections. It
> makes the standby a lot less useful if you can't rely on it being
> open. So I'd like to make it so that the standby can *always* open up.

Yes, of course. The only reason for restrictions being acceptable is
that we have 99% of what we want, yet may lose everything if we play for
100% too quickly.

The standby will open quickly in many cases, as is. There are also a
range of other ways of doing this.

> There's currently three cases where that can happen:
> 
> 1. If the subxid cache has overflown.
> 
> 2. If there's no running-xacts record after the checkpoint record for
> some reason. For example, one was written but not archive yet, or
> because the master crashed before it was written.
> 
> 3. If too many AccessExclusiveLocks was being held.
> 
> Case 3 should be pretty easy to handle. Just need to WAL log all the
> AccessExclusiveLocks, perhaps as separate WAL records (we already have
> a
> new WAL record type for logging locks) if we're worried about the
> running-xacts record growing too large. I think we could handle case 2
> if we wrote the running-xacts record *before* the checkpoint record.
> Then it would be always between the REDO pointer of the checkpoint
> record, and the checkpoint record itself, so it would always be seen
> by
> the WAL recovery. To handle case 1, we could scan pg_subtrans. It
> would
> add some amount of code and would add some more work to taking the
> running-xacts snapshot, but it could be done.

"Some amount of code" requires some amount of thought, followed by some
amount of review which takes some amount of time.

-- Simon Riggs           www.2ndQuadrant.com