Re: SSI and Hot Standby

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <robertmhaas(at)gmail(dot)com>
Cc: <simon(at)2ndquadrant(dot)com>,<drkp(at)csail(dot)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: SSI and Hot Standby
Date: 2011-01-21 05:14:35
Message-ID: 4D38C1DB0200002500039962@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2011-01-21 06:02:49 Re: pg_basebackup for streaming base backups
Previous Message KaiGai Kohei 2011-01-21 05:02:58 Re: sepgsql contrib module