Re: Fwd: Why we need to check for local buffers in BufferIsExclusiveLocked and BufferIsDirty?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Srinath Reddy <srinath2133(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fwd: Why we need to check for local buffers in BufferIsExclusiveLocked and BufferIsDirty?
Date: 2025-01-29 18:32:05
Message-ID: 2033594.1738175525@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Srinath Reddy <srinath2133(at)gmail(dot)com> writes:
> as suggested did not change the BufferIsExclusiveLocked's signature and
> here's the patch for the same.

Yeah, that's better. The whole point of changing these is to make
them do what extensions could reasonably expect, so a new API does
not seem like what's wanted.

If we cared about the speed of that assertion in XLogRegisterBuffer,
I think the thing to do would be to invent a single new function that
tests for both dirty and exclusive-locked. Really BufferIsDirty
does that already, at least in assertion builds, so we could just do

- Assert(BufferIsExclusiveLocked(buffer) && BufferIsDirty(buffer));
+ Assert(BufferIsDirty(buffer));

But I don't think we actually care that much about the speed of an
assertion, and it might be confusing since this doesn't quite
match the comment above it. So I'm inclined to leave that alone.

I pushed your patch after fooling with the comments a bit.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ilia Evdokimov 2025-01-29 18:52:21 Re: Sample rate added to pg_stat_statements
Previous Message Masahiko Sawada 2025-01-29 17:58:53 Re: Eagerly scan all-visible pages to amortize aggressive vacuum