| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Antonin Houska <ah(at)cybertec(dot)at> |
| Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: POC: Cleaning up orphaned files using undo logs |
| Date: | 2021-09-28 22:27:54 |
| Message-ID: | CA+hUKGLvQSxXnwsqU1exWuPSH7VOouG=-s1Rradw7o+rwFKzWg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 29, 2021 at 8:18 AM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> I'm just trying to use the existing infrastructure: the effect of DROP TABLE
> also appear to be performed by the checkpointer. However I don't know why the
> unlinks need to be performed by the checkpointer.
For DROP TABLE, we leave an empty file (I've been calling it a
"tombstone file") so that GetNewRelFileNode() won't let you reuse the
same relfilenode in the same checkpoint cycle. One reason is that
wal_level=minimal has a data-eating crash recovery failure mode if you
reuse a relfilenode in a checkpoint cycle.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuro Yamada | 2021-09-28 23:54:18 | Re: Add prefix pg_catalog to pg_get_statisticsobjdef_columns() in describe.c (\dX) |
| Previous Message | Michael Paquier | 2021-09-28 22:25:38 | Re: Incorrect fd handling in syslogger.c for Win64 under EXEC_BACKEND |