Обсуждение: Re: Why we need to check for local buffers in BufferIsExclusiveLocked and BufferIsDirty?

Hi,

On 2024-12-05 18:38:16 +0530, Srinath Reddy Sadipiralla wrote:
> Why we need to check for local buffers in BufferIsExclusiveLocked and
> BufferIsDirty?,these 2 functions are called only from
> XlogRegisterBuffer,AFAIK which will be called only for permanent
> relations.Please correct me if i am wrong.

That's maybe true for in-core code today, but what guarantees that that's true
for the future? And what about code in extensions?

The gain by not dealing with local buffers in these functions is fairly small
too, so there's not really any reason for a change like yours.

- Andres

Hi,

On Fri, 6 Dec 2024 at 07:03, Srinath Reddy Sadipiralla
<srinath.reddy@zohocorp.com> wrote:
>
> > ---- On Thu, 05 Dec 2024 21:11:42 +0530 Andres Freund <andres@anarazel.de> wrote ---
>
> > Hi,
>
> > On 2024-12-05 18:38:16 +0530, Srinath Reddy Sadipiralla wrote:
> >> Why we need to check for local buffers in BufferIsExclusiveLocked and
> >> BufferIsDirty?,these 2 functions are called only from
> >> XlogRegisterBuffer,AFAIK which will be called only for permanent
> >> relations.Please correct me if i am wrong.
>
> > That's maybe true for in-core code today, but what guarantees that that's true
> > for the future? And what about code in extensions?
>
> > The gain by not dealing with local buffers in these functions is fairly small
> > too, so there's not really any reason for a change like yours.
>
> > - Andres
>
>
> hmm got it,if thats the case, for local buffers lockbuffer will skip acquiring content lock, so assert will fail in
BufferIsDirty.

LGTM.

Adding Daniil to CC as he too started a similar thread [1].

[1] postgr.es/m/CAJDiXggGznOttwREfyZRE4f7oLRz1%3DjTA4xA7u-t6_8CX7j%3D0g%40mail.gmail.com

--
Regards,
Nazir Bilal Yavuz
Microsoft

Hi Srinath,

On Sat, 7 Dec 2024 at 11:17, Srinath Reddy Sadipiralla
<srinath.reddy@zohocorp.com> wrote:
> > ---- On Fri, 06 Dec 2024 16:40:51 +0530 Nazir Bilal Yavuz <byavuz81@gmail.com> wrote ---
> > LGTM.
>
> sorry i didn't get,what you meant to say is the assert failure which i said is correct and does my patch to this
looksgood?🤔 

Sorry if I was not clear. Yes, I wanted to say what you said is
correct and the patch looks good to me.

--
Regards,
Nazir Bilal Yavuz
Microsoft

Srinath Reddy Sadipiralla <srinath.reddy@zohocorp.com> writes:
>> ---- On Thu, 05 Dec 2024 21:11:42 +0530 Andres Freund <mailto:andres@anarazel.de> wrote ---
>> The gain by not dealing with local buffers in these functions is fairly small
>> too, so there's not really any reason for a change like yours.

> hmm got it,if thats the case, for local buffers lockbuffer will skip acquiring content lock, so assert will fail in
BufferIsDirty.

I think you are right about that, but

(1) it seems to be general style to check BufferIsPinned before
checking the content lock, and you've made that out-of-order.
This is easily fixed by moving the Assert(BufferIsPinned(buffer))
to earlier in the function.

(2) I don't think we should touch this but not worry about
BufferIsExclusiveLocked: it's unlikely to behave well on local
buffers either, since we don't initialize content locks for them.
We could either Assert that that's not applied to local buffers,
or act as though their lock is always held.  Given Andres' argument
probably the latter is better.

            regards, tom lane

Srinath Reddy <srinath2133@gmail.com> writes:
> as suggested did the changes and attached the patch for the same.

Uh ... what in the world is the point of changing
BufferIsExclusiveLocked's signature?

            regards, tom lane

Srinath Reddy <srinath2133@gmail.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