Re: 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: "Andres Freund" <andres(at)anarazel(dot)de>, "pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Why we need to check for local buffers in BufferIsExclusiveLocked and BufferIsDirty?
Date: 2025-01-25 21:50:40
Message-ID: 773837.1737841840@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Srinath Reddy Sadipiralla <srinath(dot)reddy(at)zohocorp(dot)com> writes:
>> ---- On Thu, 05 Dec 2024 21:11:42 +0530 Andres Freund <mailto:andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-01-25 21:55:15 Re: Convert sepgsql tests to TAP
Previous Message Tomas Vondra 2025-01-25 20:41:29 Re: Adjusting hash join memory limit to handle batch explosion