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 |
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 |