Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?

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-03-02 04:28:32
Message-ID: CA+hUKGJNm5HK1xUOgDnynCKn=_ed_N=XOcZGzCi3Fkp5j5Feqw@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:
> Right, the checkpoint itself is probably worse than this
> "close-all-your-files!" thing in some cases [...]

I've been wondering what obscure hazards these "tombstone" (for want
of a better word) files guard against, besides the one described in
the comments for mdunlink(). I've been thinking about various
schemes that can be summarised as "put the tombstones somewhere else",
but first... this is probably a stupid question, but what would break
if we just ... turned all this stuff off when wal_level is high enough
(as it is by default)?

Attachment Content-Type Size
0001-Make-relfile-tombstone-files-conditional-on-WAL-leve.not-for-cfbot-patch application/octet-stream 4.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-03-02 04:42:34 Re: 64-bit XIDs in deleted nbtree pages
Previous Message Masahiko Sawada 2021-03-02 04:06:02 Re: 64-bit XIDs in deleted nbtree pages