Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?
Date
Msg-id CA+hUKGLDkSFx8ggGkGDjMbRZO-DrB+s-4LikrKuMbWApFdiDKQ@mail.gmail.com
Whole thread Raw
In response to Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?  (Andres Freund <andres@anarazel.de>)
Responses Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?
List pgsql-hackers
On Tue, Feb 2, 2021 at 8:02 AM Andres Freund <andres@anarazel.de> wrote:
> It's probably rare enough to care, but this still made me thing whether
> we could avoid the checkpoint at all somehow. Requiring an immediate
> checkpoint for dropping relations is quite a heavy hammer that
> practically cannot be used in production without causing performance
> problems. But it seems hard to process the fsync deletion queue in
> another way.

Right, the checkpoint itself is probably worse than this
"close-all-your-files!" thing in some cases (though it seems likely
that once we start using ProcSignalBarrier we're going to find out
about places that take a long time to get around to processing them
and that's going to be a thing to work on).  As a separate project,
perhaps we should find some other way to stop GetNewRelFileNode() from
recycling the relfilenode until the next checkpoint, so that we can
unlink the file eagerly at commit time, while still avoiding the
hazard described in the comment for mdunlink().  A straw-man idea
would be to touch a file under PGDATA/pg_dropped and fsync it so it
survives a power outage, have checkpoints clean that out, and have
GetNewRelFileNode() to try access() it.  Then we wouldn't need the
checkpoint here, I think; we'd just need this ProcSignalBarrier for
Windows.

> > +void
> > +smgrrelease(void)
> > +{
> > +     mdrelease();
> > +}
>
> Probably should be something like
>         for (i = 0; i < NSmgr; i++)
>         {
>                 if (smgrsw[i].smgr_release)
>                         smgrsw[i].smgr_release();
>         }

Fixed.  Thanks!

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Key management with tests
Next
From: Andrew Dunstan
Date:
Subject: Announcing Release 12 of the PostgreSQL Buildfarm client