On Tue, Feb 2, 2021 at 8:02 AM Andres Freund <and...@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!
v3-0001-Use-a-global-barrier-to-fix-DROP-TABLESPACE-on-Wi.patch
Description: Binary data
v3-0002-Use-condition-variables-for-ProcSignalBarriers.patch
Description: Binary data
