On 2012-12-04 09:33:28 -0500, Robert Haas wrote:
> On Tue, Dec 4, 2012 at 9:00 AM, Andres Freund <andres@2ndquadrant.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.
I wouldn't want to rely on it...
> > 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.
I wonder if we could solve that by having an in-memory-only LSN that
only interlocks the hint bit writes, but doesn't cause full page
writes...
Greetings,
Andres Freund
--Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services