From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier? |
Date: | 2021-02-01 23:26:09 |
Message-ID: | CA+hUKGJ8=tkpCb5Js8wactqZHGRUsW2GcJvgUvnU6jbU=FbWcw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 2, 2021 at 11:16 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2021-02-01 23:31:32 | Re: Key management with tests |
Previous Message | Jeff Janes | 2021-02-01 23:12:38 | Re: memory leak in auto_explain |