Re: PageIsAllVisible()'s trustworthiness in Hot Standby

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PageIsAllVisible()'s trustworthiness in Hot Standby
Date: 2012-12-04 14:33:28
Message-ID: CA+TgmoYSHDp7nYNQoQm8iA=1eAzSf742jx_-cMMLVGUyArafHQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 4, 2012 at 9:00 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Youre right, it currently seems to be possible, there's no LSN interlock
> prohibiting this as far as I can see.

Yeah, there certainly isn't that. Now you could perhaps make an
argument that no operation that can propagate a set bit from master to
standby can arrive until after the standby's xmin horizon is
sufficiently current, but that does feel a little fragile to me...
even if it's true now, new WAL record types might break it, for
example.

> in lazy_scan_heap we do:
>
> if (!PageIsAllVisible(page))
> {
> PageSetAllVisible(page);
> MarkBufferDirty(buf);
> visibilitymap_set(onerel, blkno, InvalidXLogRecPtr, vmbuffer,
> visibility_cutoff_xid);
> }
>
> So buf can be written out independently from the xlog record that
> visibilitymap_set emits. ISTM we should set the LSN of the heap page as
> well as the one of the visibilitymap page. Not sure about the
> performance impact of that.

It would result in a massive increase in WAL traffic when vacuuming an
insert-only table; that's why we didn't do it originally.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-12-04 14:37:46 Re: Tablespaces in the data directory
Previous Message Andres Freund 2012-12-04 14:00:14 Re: PageIsAllVisible()'s trustworthiness in Hot Standby