Re: Is this a problem in GenericXLogFinish()?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is this a problem in GenericXLogFinish()?
Date: 2023-10-23 14:14:27
Message-ID: CA+TgmobjyWDQfiMLj1_Lf0GheiY0SaOEPbFEepfa3G-XOLmHOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 20, 2023 at 12:28 PM Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-10-23 14:19:54 Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs
Previous Message Robert Haas 2023-10-23 14:11:14 Re: controlling meson's parallelism (and some whining)