Re: BUG #18259: Assertion in ExtendBufferedRelLocal() fails after no-space-left condition
Alexander Law <exclusion@gmail.com>
From: Alexander Lakhin <exclusion@gmail.com>
To: tender wang <tndrwang@gmail.com>, pgsql-bugs@lists.postgresql.org,
Andres Freund <andres@anarazel.de>
Date: 2023-12-27T07:00:00Z
Lists: pgsql-bugs
Hello tender wang,
26.12.2023 19:55, tender wang write:
> I tried to analyze the issue, and I found that it might be caused by this commit:
> commit dad50f677c42de207168a3f08982ba23c9fc6720
> bufmgr: Acquire and clean victim buffer separately
>
Thanks for looking into it!
> ...
>
> With debug logging added in this code within ExtendBufferedRelLocal():
> if (found)
> {
> BufferDesc *existing_hdr =
> GetLocalBufferDescriptor(hresult->id);
> uint32 buf_state;
>
> UnpinLocalBuffer(BufferDescriptorGetBuffer(victim_buf_hdr));
>
> existing_hdr = GetLocalBufferDescriptor(hresult->id);
> PinLocalBuffer(existing_hdr, false);
> buffers[i] = BufferDescriptorGetBuffer(existing_hdr);
>
> buf_state = pg_atomic_read_u32(&existing_hdr->state);
> Assert(buf_state & BM_TAG_VALID);
> Assert(!(buf_state & BM_DIRTY));
> buf_state &= BM_VALID;
> pg_atomic_unlocked_write_u32(&existing_hdr->state, buf_state);
> ...
> I see that it reached for the second INSERT (and NOSPC error) with
> existing_hdr->state == 0x2040000, but for the third INSERT I observe
> state == 0x0.
>
I wonder, if "buf_state &= BM_VALID" is a typo here, maybe it supposed to be
"buf_state &= ~BM_VALID" as in ExtendBufferedRelShared()...
Best regards,
Alexander
Commits
-
Fix corruption of local buffer state during extend of temp relation
- 37c5516633c8 16.2 landed
- 9cd0d77dfcdf 17.0 landed
-
bufmgr: Acquire and clean victim buffer separately
- dad50f677c42 16.0 cited