Re: Random pg_upgrade 004_subscription test failure on drongo - Mailing list pgsql-hackers

From vignesh C
Subject Re: Random pg_upgrade 004_subscription test failure on drongo
Date
Msg-id CALDaNm1NtWVosSSb9mp3OKic60em5HF2zmURC77MLWyYLMWqyw@mail.gmail.com
Whole thread Raw
In response to Re: Random pg_upgrade 004_subscription test failure on drongo  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Fri, 21 Mar 2025 at 18:54, vignesh C <vignesh21@gmail.com> wrote:
>
> On Thu, 13 Mar 2025 at 18:10, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> >
> >
> > Hmm, this problem isn't limited to this one pg_upgrade test, right? It
> > could happen with any pg_upgrade invocation. And perhaps in a running
> > server too, if a relfilenumber is reused quickly. In dropdb() and
> > DropTableSpace() we do this:
> >
> > WaitForProcSignalBarrier(EmitProcSignalBarrier(PROCSIGNAL_BARRIER_SMGRRELEASE));
> >
> > Should we do the same here? Not sure where exactly to put that; perhaps
> > in mdcreate(), if the creation fails with STATUS_DELETE_PENDING.
>
> How about a patch similar to the attached one? I have run pg_upgrade
> tests multiple times, but unfortunately, I was unable to reproduce the
> issue or verify these changes.

CFBot reported an issue in one of the machines, here is an updated
version for the same.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Mircea Cadariu
Date:
Subject: Re: vacuumdb --analyze-only does not need to issue VACUUM (ONLY_DATABASE_STATS) ?
Next
From: Чумак Антон
Date:
Subject: Re: [PATCH] Introduce unified support for composite GUC options