Re: Disabled features on Hot Standby - Mailing list pgsql-hackers
From | Noah Misch |
---|---|
Subject | Re: Disabled features on Hot Standby |
Date | |
Msg-id | 20120114010231.GA26756@tornado.leadboat.com Whole thread Raw |
In response to | Re: Disabled features on Hot Standby (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Disabled features on Hot Standby
Re: Disabled features on Hot Standby |
List | pgsql-hackers |
On Fri, Jan 13, 2012 at 12:08:05PM -0500, Robert Haas wrote: > On Fri, Jan 13, 2012 at 11:13 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > Many WAL records have latestRemovedXid on them. We can use the same > > idea with XLOG_HEAP2_VISIBLE records, so we add a field to send the > > latest vacrelstats->latestRemovedXid. That then creates a recovery > > snapshot conflict that would cancel any query that might then see a > > page of the vis map that was written when the xmin was later than on > > the standby. If replication disconnects briefly and a vimap bit is > > updated that would cause a problem, just as the same situation would > > cause a problem because of other record types. > > That could create a lot of recovery conflicts when > hot_standby_feedback=off, I think, but it might work when > hot_standby_feedback=on. I don't fully understand the > latestRemovedXid machinery, but I guess the idea would be to kill any > standby transaction whose proc->xmin precedes the oldest committed > xmin or xmax on the page. If hot_standby_feedback=on then there > shouldn't be any, except in the case where it's just been enabled or > the SR connection is bouncing. FWIW, Tom aired the same idea here: http://archives.postgresql.org/message-id/27743.1291135210@sss.pgh.pa.us While reviewing the crash-safe visibility map patch, I echoed the idea and explained why the extra conflicts would be immaterial: http://archives.postgresql.org/message-id/20110618133703.GA1100@tornado.leadboat.com > Also, what happens if an all-visible bit gets set on the standby > through some other mechanism - e.g. restored from an FPI or > XLOG_HEAP_NEWPAGE? I'm not sure whether we ever do an FPI of the > visibility map page itself, but we certainly do it for the heap pages. > So it might be that this infrastructure would (somewhat bizarrely) > trust the visibility map bits but not the PD_ALL_VISIBLE bits. Simon spoke to the FPI side of the question. For heap pages, the XLOG_HEAP_NEWPAGE consumers are CLUSTER, VACUUM FULL and ALTER TABLE SET TABLESPACE. For the last, we will have already logged any PD_ALL_VISIBLE bits through normal channels. CLUSTER and VACUUM FULL never set PD_ALL_VISIBLE or visibility map bits. When, someday, they do, we might emit a separate WAL record to force the recovery conflict. However, CLUSTER/VACUUM FULL already remove tuples still-visible to standby snapshots without provoking a recovery conflict. (Again only with hot_standby_feedback=off.) Thanks, nm
pgsql-hackers by date: