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+hUKGJ8=tkpCb5Js8wactqZHGRUsW2GcJvgUvnU6jbU=FbWcw@mail.gmail.com
Whole thread Raw
In response to Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Tue, Feb 2, 2021 at 11:16 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> ...  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.  ...

I should add, the reason I mentioned fsyncing it is that in another
thread we've also discussed making the end-of-crash-recovery
checkpoint optional, and then I think you'd need to be sure you can
avoid reusing the relfilenode even after crash recovery, because if
you recycle the relfilenode and then crash again you'd be exposed to
that hazard during the 2nd run thought recovery.  But perhaps it's
enough to recreate the hypothetical pg_dropped file while replaying
the drop-relation record.  Not sure, would need more thought.



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: memory leak in auto_explain
Next
From: Stephen Frost
Date:
Subject: Re: Key management with tests