Re: Is this a problem in GenericXLogFinish()? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Is this a problem in GenericXLogFinish()?
Date
Msg-id CA+TgmobjyWDQfiMLj1_Lf0GheiY0SaOEPbFEepfa3G-XOLmHOA@mail.gmail.com
Whole thread Raw
In response to Re: Is this a problem in GenericXLogFinish()?  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Is this a problem in GenericXLogFinish()?
List pgsql-hackers
On Fri, Oct 20, 2023 at 12:28 PM Jeff Davis <pgsql@j-davis.com> wrote:
> I still have a question though: if a buffer is exclusive-locked,
> unmodified and clean, and then the caller registers it and later does
> PageSetLSN (just as if it were dirty), is that a definite bug?
>
> There are a couple callsites where the control flow is complex enough
> that it's hard to be sure the buffer is always marked dirty before
> being registered (like in log_heap_visible(), as I mentioned upthread).
> But those callsites are all doing PageSetLSN, unlike the hash index
> case.

I think that would be a bug. I think it would be OK to just change the
page LSN and nothing else, but that requires calling MarkBufferDirty()
at some point. If you only call PageSetLSN() and never
MarkBufferDirty(), that sounds messed up: either the former should be
skipped, or the latter should be added. We shouldn't modify a shared
buffer without marking it dirty.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: controlling meson's parallelism (and some whining)
Next
From: Andrew Dunstan
Date:
Subject: Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs