On 2 February 2013 18:38, Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-02-02 18:32:44 +0000, Simon Riggs wrote: >> On 2 February 2013 14:24, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers