Re: PageIsAllVisible()'s trustworthiness in Hot Standby
От | Andres Freund |
---|---|
Тема | Re: PageIsAllVisible()'s trustworthiness in Hot Standby |
Дата | |
Msg-id | 20121204153834.GA12055@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: PageIsAllVisible()'s trustworthiness in Hot Standby (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: PageIsAllVisible()'s trustworthiness in Hot Standby
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: