From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Петър Славов <pet.slavov@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Date: Mon, 23 May 2022 14:40:16 +0900
Message-ID: <YoseQAkUMCEvlxhn@paquier.xyz> (raw)
In-Reply-To: <202205191203.zzmne46ulpbu@alvherre.pgsql>
References: <YoX5mCtugHdB5OET@paquier.xyz>
<202205191203.zzmne46ulpbu@alvherre.pgsql>
On Thu, May 19, 2022 at 02:03:56PM +0200, Alvaro Herrera wrote:
> Hmm, yes, it's definitely possible that it is related.
>
> I'll have a look soon.
It took me some time to write a script to bisect that, but I have been
able to establish a correlation with d9d0762 that causes VACUUM to
ignore transactions doing some concurrent reindex operations. I would
not be surprised to see that this is also related to some of the
reports we have seen lately with reindex operations. There was one
with logical replication and missing records from a primary key, I
recall.
For the stable branches of 14 and 15, I would tend to play it safe and
revert d9d0762. I have to admit that f9900df and c98763b stress me a
bit, and that we have not have anticipated all the ramifications of
this set of changes. Thoughts?
--
Michael
Attachments:0001-Revert-VACUUM-ignore-indexing-operations-with-CONCUR.patch (text/x-diff, 6.5K) download
From 8568ecb968b2a3a8b5b535546fee5bb1589db1d7 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@paquier.xyz>
Date: Mon, 23 May 2022 14:25:22 +0900
Subject: [PATCH] Revert "VACUUM: ignore indexing operations with CONCURRENTLY"
This reverts commit d9d076222f5b94a85e0e318339cfc44b8f26022d.
---
src/backend/storage/ipc/procarray.c | 41 ++++++-----------------------
src/backend/utils/misc/guc.c | 2 +-
doc/src/sgml/ref/create_index.sgml | 2 --
doc/src/sgml/ref/reindex.sgml | 2 --
4 files changed, 9 insertions(+), 38 deletions(-)
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.cindex cd58c5faf0..21b468b5a8 100644--- a/src/backend/storage/ipc/procarray.c+++ b/src/backend/storage/ipc/procarray.c@@ -1659,13 +1659,7 @@ TransactionIdIsActive(TransactionId xid)
* relations that's not required, since only backends in my own database could
* ever see the tuples in them. Also, we can ignore concurrently running lazy
* VACUUMs because (a) they must be working on other tables, and (b) they
- * don't need to do snapshot-based lookups. Similarly, for the non-catalog- * horizon, we can ignore CREATE INDEX CONCURRENTLY and REINDEX CONCURRENTLY- * when they are working on non-partial, non-expressional indexes, for the- * same reasons and because they can't run in transaction blocks. (They are- * not possible to ignore for catalogs, because CIC and RC do some catalog- * operations.) Do note that this means that CIC and RC must use a lock level- * that conflicts with VACUUM.+ * don't need to do snapshot-based lookups.
*
* This also computes a horizon used to truncate pg_subtrans. For that
* backends in all databases have to be considered, and concurrently running
@@ -1715,6 +1709,9 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
bool in_recovery = RecoveryInProgress();
TransactionId *other_xids = ProcGlobal->xids;
+ /* inferred after ProcArrayLock is released */+ h->catalog_oldest_nonremovable = InvalidTransactionId;+
LWLockAcquire(ProcArrayLock, LW_SHARED);
h->latest_completed = ShmemVariableCache->latestCompletedXid;
@@ -1734,7 +1731,6 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
h->oldest_considered_running = initial;
h->shared_oldest_nonremovable = initial;
- h->catalog_oldest_nonremovable = initial;
h->data_oldest_nonremovable = initial;
/*
@@ -1805,7 +1801,7 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
if (statusFlags & (PROC_IN_VACUUM | PROC_IN_LOGICAL_DECODING))
continue;
- /* shared tables need to take backends in all databases into account */+ /* shared tables need to take backends in all database into account */
h->shared_oldest_nonremovable =
TransactionIdOlder(h->shared_oldest_nonremovable, xmin);
@@ -1833,25 +1829,11 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
(statusFlags & PROC_AFFECTS_ALL_HORIZONS) ||
in_recovery)
{
- /*- * We can ignore this backend if it's running CREATE INDEX- * CONCURRENTLY or REINDEX CONCURRENTLY on a "safe" index -- but- * only on vacuums of user-defined tables.- */- if (!(statusFlags & PROC_IN_SAFE_IC))- h->data_oldest_nonremovable =- TransactionIdOlder(h->data_oldest_nonremovable, xmin);-- /* Catalog tables need to consider all backends in this db */- h->catalog_oldest_nonremovable =- TransactionIdOlder(h->catalog_oldest_nonremovable, xmin);+ h->data_oldest_nonremovable =+ TransactionIdOlder(h->data_oldest_nonremovable, xmin);
}
}
- /* catalog horizon should never be later than data */- Assert(TransactionIdPrecedesOrEquals(h->catalog_oldest_nonremovable,- h->data_oldest_nonremovable));-
/*
* If in recovery fetch oldest xid in KnownAssignedXids, will be applied
* after lock is released.
@@ -1873,8 +1855,6 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
TransactionIdOlder(h->shared_oldest_nonremovable, kaxmin);
h->data_oldest_nonremovable =
TransactionIdOlder(h->data_oldest_nonremovable, kaxmin);
- h->catalog_oldest_nonremovable =- TransactionIdOlder(h->catalog_oldest_nonremovable, kaxmin);
/* temp relations cannot be accessed in recovery */
}
else
@@ -1901,9 +1881,6 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
h->data_oldest_nonremovable =
TransactionIdRetreatedBy(h->data_oldest_nonremovable,
vacuum_defer_cleanup_age);
- h->catalog_oldest_nonremovable =- TransactionIdRetreatedBy(h->catalog_oldest_nonremovable,- vacuum_defer_cleanup_age);
/* defer doesn't apply to temp relations */
}
@@ -1926,9 +1903,7 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
h->shared_oldest_nonremovable =
TransactionIdOlder(h->shared_oldest_nonremovable,
h->slot_catalog_xmin);
- h->catalog_oldest_nonremovable =- TransactionIdOlder(h->catalog_oldest_nonremovable,- h->slot_xmin);+ h->catalog_oldest_nonremovable = h->data_oldest_nonremovable;
h->catalog_oldest_nonremovable =
TransactionIdOlder(h->catalog_oldest_nonremovable,
h->slot_catalog_xmin);
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.cindex 8e9b71375c..5478762cdb 100644--- a/src/backend/utils/misc/guc.c+++ b/src/backend/utils/misc/guc.c@@ -2740,7 +2740,7 @@ static struct config_int ConfigureNamesInt[] =
NULL
},
&vacuum_defer_cleanup_age,
- 0, 0, 1000000, /* see ComputeXidHorizons */+ 0, 0, 1000000,
NULL, NULL, NULL
},
{
diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgmlindex 907324b93e..9ffcdc629e 100644--- a/doc/src/sgml/ref/create_index.sgml+++ b/doc/src/sgml/ref/create_index.sgml@@ -861,8 +861,6 @@ Indexes:
Like any long-running transaction, <command>CREATE INDEX</command> on a
table can affect which tuples can be removed by concurrent
<command>VACUUM</command> on any other table.
- Excepted from this are operations with the <literal>CONCURRENTLY</literal>- option for indexes that are not partial and do not index any expressions.
</para>
<para>
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgmlindex 36cb4a455b..336ca24b31 100644--- a/doc/src/sgml/ref/reindex.sgml+++ b/doc/src/sgml/ref/reindex.sgml@@ -475,8 +475,6 @@ Indexes:
Like any long-running transaction, <command>REINDEX</command> on a table
can affect which tuples can be removed by concurrent
<command>VACUUM</command> on any other table.
- Excepted from this are operations with the <literal>CONCURRENTLY</literal>- option for indexes that are not partial and do not index any expressions.
</para>
<para>
--
2.36.1
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: michael@paquier.xyz, alvherre@alvh.no-ip.org, pet.slavov@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
In-Reply-To: <YoseQAkUMCEvlxhn@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox