diff options
| author | Andres Freund <andres@anarazel.de> | 2020-10-28 21:48:38 -0700 |
|---|---|---|
| committer | Andres Freund <andres@anarazel.de> | 2020-10-28 21:49:07 -0700 |
| commit | 1c7675a7a4265064a2c8e1ed02b2c042c2521664 (patch) | |
| tree | 64d1a1a0cfeaabeeae54ac49eb279e63e7c6a32d /src | |
| parent | 8e90ec5580d5345fef31005d7cc2215ba2125070 (diff) | |
| download | postgresql-1c7675a7a4265064a2c8e1ed02b2c042c2521664.tar.gz postgresql-1c7675a7a4265064a2c8e1ed02b2c042c2521664.zip | |
Fix wrong data table horizon computation during backend startup.
When ComputeXidHorizons() was called before MyDatabaseOid is set,
e.g. because a dead row in a shared relation is encountered during
InitPostgres(), the horizon for normal tables was computed too
aggressively, ignoring all backends connected to a database.
During subsequent pruning in a data table the too aggressive horizon
could end up still being used, possibly leading to still needed tuples
being removed. Not good.
This is a bug in dc7420c2c92, which the test added in 94bc27b5768 made
visible, if run with force_parallel_mode set to regress. In that case
the bug is reliably triggered, because "pruning_query" is run in a
parallel worker and the start of that parallel worker is likely to
encounter a dead row in pg_database.
The fix is trivial: Compute a more pessimistic data table horizon if
MyDatabaseId is not yet known.
Author: Andres Freund
Discussion: https://postgr.es/m/20201029040030.p4osrmaywhqaesd4@alap3.anarazel.de
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/storage/ipc/procarray.c | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c index ee4caa51152..8da7b1d8a7b 100644 --- a/src/backend/storage/ipc/procarray.c +++ b/src/backend/storage/ipc/procarray.c @@ -1757,9 +1757,16 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h) * the shared horizon. But in recovery we cannot compute an accurate * per-database horizon as all xids are managed via the * KnownAssignedXids machinery. + * + * Be careful to compute a pessimistic value when MyDatabaseId is not + * set. If this is a backend in the process of starting up, we may not + * use a "too aggressive" horizon (otherwise we could end up using it + * to prune still needed data away). If the current backend never + * connects to a database that is harmless, because + * data_oldest_nonremovable will never be utilized. */ if (in_recovery || - proc->databaseId == MyDatabaseId || + MyDatabaseId == InvalidOid || proc->databaseId == MyDatabaseId || proc->databaseId == 0) /* always include WalSender */ { h->data_oldest_nonremovable = |