Thomas Munro <thomas.mu...@gmail.com> wrote:
> On Wed, Sep 29, 2021 at 8:18 AM Antonin Houska <a...@cybertec.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.
Interesting. Is the problem that REDO of the DROP TABLE command deletes the
relfilenode which already contains the new data, but the new data cannot be
recovered because (due to wal_level=minimal) it's not present in WAL? In this
case I suppose that the checkpoint just ensures that the DROP TABLE won't be
replayed during the next crash recovery.
BTW, does that comment fix attached make sense to you? The corresponding code
in InitSync() is
/*
* Create pending-operations hashtable if we need it. Currently, we
need
* it if we are standalone (not under a postmaster) or if we are a
* checkpointer auxiliary process.
*/
if (!IsUnderPostmaster || AmCheckpointerProcess())
I suspect this is also related to the commit 7ff23c6d27.
Thanks for your answer, I was considering to add you to CC :-)
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/storage/sync/sync.c b/src/backend/storage/sync/sync.c
index 1c78581354..ae6c5ff8e4 100644
--- a/src/backend/storage/sync/sync.c
+++ b/src/backend/storage/sync/sync.c
@@ -563,7 +563,7 @@ RegisterSyncRequest(const FileTag *ftag, SyncRequestType type,
if (pendingOps != NULL)
{
- /* standalone backend or startup process: fsync state is local */
+ /* standalone backend or checkpointer process: fsync state is local */
RememberSyncRequest(ftag, type);
return true;
}
