Re: md.c vs elog.c vs smgrreleaseall() in barrier - Mailing list pgsql-hackers

From Andres Freund
Subject Re: md.c vs elog.c vs smgrreleaseall() in barrier
Date
Msg-id f33yxgfpmcqpzvu7vvy2rvuxm3igyqgrys3obpz2o2xkao7svw@b7g33yljiw62
Whole thread Raw
In response to Re: md.c vs elog.c vs smgrreleaseall() in barrier  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

On 2025-03-17 19:52:02 -0400, Andres Freund wrote:
> On 2025-03-14 12:57:51 +1300, Thomas Munro wrote:
> > On Fri, Mar 14, 2025 at 12:23 PM Andres Freund <andres@anarazel.de> wrote:
> > 
> > > > 3.  Considering errfinish()'s stated goal, a sort of backstop to help
> > > > you cancel looping message-spewing code only, I wonder if we should
> > > > just restrict the kinds of interrupts it processes, so that it only
> > > > calls CFI() if we're definitely throwing ERROR or FATAL?
> > >
> > > I'm not even sure it'd be safe to ERROR out in all the relevant places...
> > >
> > > E.g.
> > >                 /* implementation-specific initialization */
> > >                 smgrsw[reln->smgr_which].smgr_open(reln);
> > >
> > >                 /* it is not pinned yet */
> > >                 reln->pincount = 0;
> > >                 dlist_push_tail(&unpinned_relns, &reln->node);
> > >
> > > doesn't this mean that ->pincount is uninitialized in case smgr_open() errors
> > > out and that we'd loose track of the reln because it wasn't yet added to
> > > unpinned_rels?
> > 
> > Ugh, right.
> 
> Patch for that attached.

The patch claimed:

> This buglet was introduced in 21d9c3ee4ef7. As that commit is only in HEAD, no
> need to backpatch.

But looking at it again that's unfortunately not true. Turns out it's not
2024 anymore...  Planning to backpatch that part to 17 soon.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: optimize file transfer in pg_upgrade
Next
From: Nathan Bossart
Date:
Subject: Re: optimize file transfer in pg_upgrade