On Fri, Jan 13, 2012 at 3:22 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jan 13, 2012 at 10:17 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas <robertmh...@gmail.com> wrote: >> >>> Since the xmin horizon on the standby may precede the xmin horizon on >>> the master >> >> When hot_standby_feedback is turned on, the xmin of the standby is >> provided to the master to ensure the situation you describe never >> happens. >> >> Surely that means the problem is solved, if we can confirm the setting >> of the parameter. So this seems like a cleanup issues that can/should >> be resolved. > > How do you respond to the concerns I raised about that approach in the > last sentence of my previous email?
I think it should be you that comes up with a fix, not for me to respond to your concerns about how hard it is. Many things that don't fully work are rejected for that reason. Having said that, I have input that seems to solve the problem. 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. If problem solved then we can enable IndexOnlyScans on standby. -- 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
