On Fri, Jan 13, 2012 at 3:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jan 13, 2012 at 10:17 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas <robertmhaas@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
