| 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: | Whole Thread | Raw Message | 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 |