Re: GetOldestXmin going backwards is dangerous after all

On 2 February 2013 18:38, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-02-02 18:32:44 +0000, Simon Riggs wrote:
>> 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.
>
> Not trivial, but not too hard, yes. When the standby initially connects
> we don't yet know which xid will be required because consistency hasn't
> yet been achieved.

We don't need to change the protocol, we just need to issue a
hot_standby_feedback message immediately after connection.

That looks trivial to me.

>> > 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.
>
> Thats easy enough when the standby is initially started but doesn't work
> that well if just the connection between both failed (or the master was
> restarted) and a reconnect worked. To make it work similarly in that
> case we would have to throw everyone out which would kind of counteract
> the whole idea.

Agreed. It was worth considering, at least.

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