Re: md.c vs elog.c vs smgrreleaseall() in barrier

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(at)anarazel(dot)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