Fix replay of create database record for missing tablespace. #1585
Open
Fix replay of create database record for missing tablespace. #1585
Conversation
…t but we need them when re-redoing some tablespace related xlogs (e.g. database create with a tablespace) on mirror." This reverts commit 7a09e80.
Crash recovery on standby may encounter missing directories
when replaying database-creation WAL records. Prior to this
patch, the standby would fail to recover in such a case;
however, the directories could be legitimately missing.
Consider the following sequence of commands:
CREATE DATABASE
DROP DATABASE
DROP TABLESPACE
If, after replaying the last WAL record and removing the
tablespace directory, the standby crashes and has to replay the
create database record again, crash recovery must be able to continue.
A fix for this problem was already attempted in 49d9cfc, but it
was reverted because of design issues. This new version is based
on Robert Haas' proposal: any missing tablespaces are created
during recovery before reaching consistency. Tablespaces
are created as real directories, and should be deleted
by later replay. CheckRecoveryConsistency ensures
they have disappeared.
The problems detected by this new code are reported as PANIC,
except when allow_in_place_tablespaces is set to ON, in which
case they are WARNING. Apart from making tests possible, this
gives users an escape hatch in case things don't go as planned.
Author: Kyotaro Horiguchi <[email protected]>
Author: Asim R Praveen <[email protected]>
Author: Paul Guo <[email protected]>
Reviewed-by: Anastasia Lubennikova <[email protected]> (older versions)
Reviewed-by: Fujii Masao <[email protected]> (older versions)
Reviewed-by: Michaël Paquier <[email protected]>
Diagnosed-by: Paul Guo <[email protected]>
Discussion: https://postgr.es/m/CAEET0ZGx9AvioViLf7nbR_8tH9-=27DN5xWJ2P9-ROH16e4JUA@mail.gmail.com
On FreeBSD, the new test fails due to a WAL file being removed before the standby has had the chance to copy it. Fix by adding a replication slot to prevent the removal until after the standby has connected. Author: Kyotaro Horiguchi <[email protected]> Reported-by: Matthias van de Meent <[email protected]> Discussion: https://postgr.es/m/CAEze2Wj5nau_qpjbwihvmXLfkAWOZ5TKdbnqOc6nKSiRJEoPyQ@mail.gmail.com
reshke
force-pushed
the
fix_for_db_records
branch
from
db3224c to
d341ee6
Compare
x4m
approved these changes
Mar 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There was a problem in GPDB/Cloudberry with DROP tablespace and create+drop database in-between.
From 2f0a2f8 commit message:
This problem was fixed in gpdb by 7a09e80
Its commit message says
Let's revert or update the code change after the solution is finalized on upstream.Actually, later, fix to upstream (PostgreSQL) was committed, and this fix is little different from our.
This PR revert commit 7a09e80 and applies upstreams fix.