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
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 |