Re: BUG #18259: Assertion in ExtendBufferedRelLocal() fails after no-space-left condition

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: tender wang <tndrwang(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: BUG #18259: Assertion in ExtendBufferedRelLocal() fails after no-space-left condition
Date: 2023-12-31 06:38:30
Message-ID: ZZEMZsgslgqfYzJH@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Dec 28, 2023 at 02:36:46PM +0800, Richard Guo wrote:
> On Wed, Dec 27, 2023 at 5:08 PM tender wang <tndrwang(at)gmail(dot)com> wrote:

(Tender Wang.. I know somebody with this name while doing Postgres
stuff in the past, are you the same guy?)

>> Yeah, that's true. I analyze this issue again, and I think the root cause
>> is the " buf_state &= BM_VALID" .
>
> Nice catch. I believe the intention is to clear the BM_VALID bit.

Hmm. Yeah. I'd need to think about that a bit more carefully, but it
looks like you are right here.. Nice catch. That looks like an
unfortunate typo from 31966b151e6a when local buffers are handled.

> By the way, I wonder if it would be worthwhile to define new macros for
> bit operations such as set_bit, clear_bit, test_bit, and so on, so that
> we can avoid such typos in the future.

Not sure. This is hiding the code behind more layers without bringing
extra value if you know how to read bitwise operations, which is
something I'd expect somebody to get pretty good at when hacking on
Postgres because that's all around the code tree. And this would
create conflict noises when backpatching. Hence, -1.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael B. Williams 2023-12-31 11:32:10 Segmentation fault caused by Postgrest - reateplan.c:6178 - prepare_sort_from_pathkeys
Previous Message David Rowley 2023-12-31 03:24:54 Re: BUG #18264: Table has type text, but query expects integer.attribute 1 of type record has wrong type