Re: BUG #18426: Canceling vacuum while truncating a relation leads to standby PANIC

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18426: Canceling vacuum while truncating a relation leads to standby PANIC
Date: 2024-04-12 06:41:30
Message-ID: CA+hUKGLbEARhvBXPL45VniV9O4h5AUocQXJ4YHrMVvK2=0JpFQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Apr 11, 2024 at 6:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> 10.04.2024 14:00, PG Bug reporting form wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 18426
> > ...
> > A demo test for the issue to follow...

I didn't try your test but your explanation seems clear.
RelationTruncate() logs first, then calls smgrtruncate() which drops
buffers and then truncates files. The dropping-the-buffers phase is
now interruptible, since commit d87251048a0f. If you interrupt it
there, the situation is bad: you have logged the truncation, but left
(1) buffers and (2) untruncated files on the primary. Relation size
being out of sync is a recipe for that PANIC next time the WAL
mentions blocks past the (primary's) end. First thought is that that
particular wait might need to hold interrupts. Hmm. The comments for
RelationTruncate() contemplate but reject a critical section.
Presumably it's waiting for another backend to flush data, and that
other backend will eventually finish doing that or fail/crash.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Munro 2024-04-12 06:43:37 Re: BUG #18426: Canceling vacuum while truncating a relation leads to standby PANIC
Previous Message Tom Lane 2024-04-12 03:46:49 Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF