Re: SSI and Hot Standby - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: SSI and Hot Standby
Date
Msg-id 4D38C1DB0200002500039962@gw.wicourts.gov
Whole thread Raw
In response to SSI and Hot Standby  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
Robert Haas  wrote:
> Kevin Grittner  wrote:
>> As I mentioned in another email, we might want to throttle this.
>> My thinking was that we could start a timer on capturing a
>> snapshot, and continue to gather new ones as they become
>> available. When you hit the timer limit (maybe 100ms?) you send
>> the latest snapshot, if you have a new one; otherwise you keep
>> trying and send one as soon as you get it.
>
> I think this is likely to suck. That's introducing 10 not-small
> XLOG records per second just in case someone happens to try to
> start a serializable transaction on a standby server.
That depends on whether we can pull off the idea for not sending the
snapshot itself which I mentioned.  But that idea is pretty sketchy
at the moment.  I can't swear we can make that work, but if we can,
it should use a lot less WAL space.
> A possibly-viable alternative would be to build something into the
> SR protocol to allow the standby to request a workable snapshot
> from the master, and the master to send it (out-of-band with
> respect to the WAL stream) when so requested.
If we can make that work, that has advantages.
> it seems like there could be starvation problems - is there an
> upper bound on the length of time it would take the master to
> generate a safe snapshot for the standby to use?
Unfortunately, to get a safe snapshot you need to grab a candidate
snapshot and wait for all serializable read write transactions which
were active at the time to complete.  At a minimum.  If any of them
develop the wrong pattern of rw-dependencies you have to discard it,
grab a new snapshot, and try again.  I suspect that most of the time
you will succeed on the first snapshot, and so will be able to call
it safe when the last concurrent serializable read write transaction
completes, but that *could* be a long time, and there is no upper
bound.
That's why I was suggesting that we try to keep a fairly current safe
snapshot sitting on the standby and use it when a serializable
transaction is requested.  Unless you request DEFERRABLE, in which
case you would wait for the *next* one to arrive.
I keep looking for another angle on this, but I'm not finding it.
I've *thought* I had something a couple times this evening while
tossing it around in my head, but the ideas fall apart on closer
inspection.  :-(
-Kevin


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: sepgsql contrib module
Next
From: Marko Tiikkaja
Date:
Subject: Re: Transaction-scope advisory locks