From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Antonin Houska <ah(at)cybertec(dot)at>, Ants Aasma <ants(at)cybertec(dot)at>, Sasasu <i(at)sasa(dot)su>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: storing an explicit nonce |
Date: | 2021-10-12 14:39:53 |
Message-ID: | 20211012143953.GH20998@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Mon, Oct 11, 2021 at 1:30 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Regarding unlogged LSNs at least, I would think that we'd want to
> > actually use GetFakeLSNForUnloggedRel() instead of just having it zero'd
> > out. The fixed value for GiST index pages is just during the index
> > build process, as I recall, and that's perhaps less of a concern. Part
> > of the point of using XTS is to avoid the issue of the LSN not being
> > changed when hint bits are, or more generally not being unique in
> > various cases.
>
> I don't believe there's anything to prevent the fake-LSN counter from
> overtaking the real end-of-WAL, and if that should happen, then the
> buffer manager would get confused. Maybe that can be fixed by doing
> some sort of surgery on the buffer manager, but it doesn't seem to be
> a trivial or ignorable problem.
Using fake LSNs isn't new.. how is this not a concern already then?
Also wondering why the buffer manager would care about the LSN on pages
which are not BM_PERMANENT..?
I'll admit that I might certainly be missing something here.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-10-12 14:40:54 | Re: pg14 psql broke \d datname.nspname.relname |
Previous Message | Mark Dilger | 2021-10-12 14:37:58 | Re: pg14 psql broke \d datname.nspname.relname |