Re: GetOldestXmin going backwards is dangerous after all

On 2 February 2013 14:24, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:

> b) We don't assign the xmin early enough, we only set it when the first
> feedback message arrives, but we should set it when walsender starts
> streaming.

That's easy to fix.

> c) After a disconnect the feedback message will rather likely ask for an
> xmin horizon thats not valid anymore on the primary. If the disconnect
> was short enough often enough that doesn't matter because nothing has
> been cleared out, but it doesn't really work all that well.
> Thats still better than setting it to the currently valid minimal xmin
> horizon because it prevents cleanup from that moment on.
> I don't see how this can be significantly improved without persistent
> knowledge about standbys.

We could delay startup of the standby until the xmin on the standby
reaches the xmin on the master.

So when the standby has hot_standby_feedback = on, at standby
connection we set the xmin of the walsender to be the current value on
the master, then we disallow connections on standby until we have
replayed up to that xmin on the standby. That way the xmin of the
walsender never goes backwards nor do we get cancelations on the
standby.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services