Re: BUG #18258: The redo of the drop db wal needs to forward the Min Recovery Point

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: shihao zhong <zhong950419(at)gmail(dot)com>
Cc: azurezhao8369(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: BUG #18258: The redo of the drop db wal needs to forward the Min Recovery Point
Date: 2026-11-13 06:58:15
Message-ID: avazyjRquSzSg99f@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Nov 09, 2026 at 10:29:45PM -0500, shihao zhong wrote:
> DROP TABLESPACE and ALTER DATABASE SET TABLESPACE have the same gap.
> The patch calls XLogFlush() before the files are removed, like
> xact_redo_commit() does. The new TAP test fails without the fix and
> passes with it.

@@ -1555,6 +1555,9 @@ tblspc_redo(XLogReaderState *record)
/* Close all smgr fds in all backends. */
WaitForProcSignalBarrier(EmitProcSignalBarrier(PROCSIGNAL_BARRIER_SMGRRELEASE));

+ /* Update minimum recovery point first, as in dbase_redo() */
+ XLogFlush(record->EndRecPtr);
+
/*
* If we issued a WAL record for a drop tablespace it implies that
* there were no files in it at all when the DROP was done. That means

Hmm. You may be right here. I would bet that this area of the code
has already been discussed regarding this problem, but perhaps my
fuzzy memories are failing me. Did you do a search of the mailing
lists regarding that?

I was wondering if this is worth the cycles spent on to begin with,
but we already have a 033_replay_tsp_drops.pl that serves this exact
purpose, so perhaps we do.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Staroverov Ilja 2026-11-13 07:34:10 Re: VACUUM/ANALYZE double-count the backend's own pending table stats
Previous Message shveta malik 2026-11-13 06:28:57 Re: BUG #19864: pg_get_publication_tables() gets cache lookup error after concurrent DROP PUBLICATION