Re: PageIsAllVisible()'s trustworthiness in Hot Standby
От | Robert Haas |
---|---|
Тема | Re: PageIsAllVisible()'s trustworthiness in Hot Standby |
Дата | |
Msg-id | CA+TgmoYSHDp7nYNQoQm8iA=1eAzSf742jx_-cMMLVGUyArafHQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PageIsAllVisible()'s trustworthiness in Hot Standby (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: PageIsAllVisible()'s trustworthiness in Hot Standby
Re: PageIsAllVisible()'s trustworthiness in Hot Standby |
Список | pgsql-hackers |
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. > 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
В списке pgsql-hackers по дате отправления: