Skip site navigation (1) Skip section navigation (2)

Re: Disabled features on Hot Standby

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Disabled features on Hot Standby
Date: 2012-01-14 01:02:31
Message-ID: 20120114010231.GA26756@tornado.leadboat.com (view raw or flat)
Thread:
Lists: 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(at)2ndquadrant(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Greg SmithDate: 2012-01-14 04:55:47
Subject: Speed dblink using alternate libpq tuple storage
Previous:From: Andres FreundDate: 2012-01-14 00:23:20
Subject: Re: Command Triggers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group