public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v4 4/5] Add documentation for ALTER SUBSCRIPTION...ADD/DROP PUBLICATION
72+ messages / 8 participants
[nested] [flat]
* [PATCH v4 4/5] Add documentation for ALTER SUBSCRIPTION...ADD/DROP PUBLICATION
@ 2021-01-26 09:54 Japin Li <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Japin Li @ 2021-01-26 09:54 UTC (permalink / raw)
---
doc/src/sgml/ref/alter_subscription.sgml | 65 ++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/doc/src/sgml/ref/alter_subscription.sgml b/doc/src/sgml/ref/alter_subscription.sgml
index db5e59f707..e6e81ce7a3 100644
--- a/doc/src/sgml/ref/alter_subscription.sgml
+++ b/doc/src/sgml/ref/alter_subscription.sgml
@@ -23,6 +23,8 @@ PostgreSQL documentation
<synopsis>
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> CONNECTION '<replaceable>conninfo</replaceable>'
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> SET PUBLICATION <replaceable class="parameter">publication_name</replaceable> [, ...] [ WITH ( <replaceable class="parameter">set_publication_option</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
+ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> ADD PUBLICATION <replaceable class="parameter">publication_name</replaceable> [, ...] [ WITH ( <replaceable class="parameter">set_publication_option</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
+ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> DROP PUBLICATION <replaceable class="parameter">publication_name</replaceable> [, ...] [ WITH ( <replaceable class="parameter">set_publication_option</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> REFRESH PUBLICATION [ WITH ( <replaceable class="parameter">refresh_option</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> ENABLE
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> DISABLE
@@ -107,6 +109,69 @@ ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> RENAME TO <
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><literal>ADD PUBLICATION <replaceable class="parameter">publication_name</replaceable></literal></term>
+ <listitem>
+ <para>
+ Add list of publications to subscription. See
+ <xref linkend="sql-createsubscription"/> for more information.
+ By default this command will also act like <literal>REFRESH
+ PUBLICATION</literal>, except it only affect on added publications.
+ </para>
+
+ <para>
+ <replaceable>set_publication_option</replaceable> specifies additional
+ options for this operation. The supported options are:
+
+ <variablelist>
+ <varlistentry>
+ <term><literal>refresh</literal> (<type>boolean</type>)</term>
+ <listitem>
+ <para>
+ When false, the command will not try to refresh table information.
+ <literal>REFRESH PUBLICATION</literal> should then be executed separately.
+ The default is <literal>true</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ Additionally, refresh options as described
+ under <literal>REFRESH PUBLICATION</literal> may be specified.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>DROP PUBLICATION <replaceable class="parameter">publication_name</replaceable></literal></term>
+ <listitem>
+ <para>
+ Drop list of publications from subscription. See
+ <xref linkend="sql-createsubscription"/> for more information.
+ By default this command will also act like <literal>REFRESH
+ PUBLICATION</literal>, except it only affect on dropped publications.
+ </para>
+
+ <para>
+ <replaceable>set_publication_option</replaceable> specifies additional
+ options for this operation. The supported options are:
+
+ <variablelist>
+ <varlistentry>
+ <term><literal>refresh</literal> (<type>boolean</type>)</term>
+ <listitem>
+ <para>
+ When false, the command will not try to refresh table information.
+ <literal>REFRESH PUBLICATION</literal> should then be executed separately.
+ The default is <literal>true</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><literal>REFRESH PUBLICATION</literal></term>
<listitem>
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v4-0005-Add-tab-complete-for-ALTER-SUBSCRIPTION.ADD-DROP.patch
^ permalink raw reply [nested|flat] 72+ messages in thread
* Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-11-22 02:13 Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2021-11-22 02:13 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>; +Cc: Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>
Attached WIP patch series significantly simplifies the definition of
scanned_pages inside vacuumlazy.c. Apart from making several very
tricky things a lot simpler, and moving more complex code outside of
the big "blkno" loop inside lazy_scan_heap (building on the Postgres
14 work), this refactoring directly facilitates 2 new optimizations
(also in the patch):
1. We now collect LP_DEAD items into the dead_tuples array for all
scanned pages -- even when we cannot get a cleanup lock.
2. We now don't give up on advancing relfrozenxid during a
non-aggressive VACUUM when we happen to be unable to get a cleanup
lock on a heap page.
Both optimizations are much more natural with the refactoring in
place. Especially #2, which can be thought of as making aggressive and
non-aggressive VACUUM behave similarly. Sure, we shouldn't wait for a
cleanup lock in a non-aggressive VACUUM (by definition) -- and we
still don't in the patch (obviously). But why wouldn't we at least
*check* if the page has tuples that need to be frozen in order for us
to advance relfrozenxid? Why give up on advancing relfrozenxid in a
non-aggressive VACUUM when there's no good reason to?
See the draft commit messages from the patch series for many more
details on the simplifications I am proposing.
I'm not sure how much value the second optimization has on its own.
But I am sure that the general idea of teaching non-aggressive VACUUM
to be conscious of the value of advancing relfrozenxid is a good one
-- and so #2 is a good start on that work, at least. I've discussed
this idea with Andres (CC'd) a few times before now. Maybe we'll need
another patch that makes VACUUM avoid setting heap pages to
all-visible without also setting them to all-frozen (and freezing as
necessary) in order to really get a benefit. Since, of course, a
non-aggressive VACUUM still won't be able to advance relfrozenxid when
it skipped over all-visible pages that are not also known to be
all-frozen.
Masahiko (CC'd) has expressed interest in working on opportunistic
freezing. This refactoring patch seems related to that general area,
too. At a high level, to me, this seems like the tuple freezing
equivalent of the Postgres 14 work on bypassing index vacuuming when
there are very few LP_DEAD items (interpret that as 0 LP_DEAD items,
which is close to the truth anyway). There are probably quite a few
interesting opportunities to make VACUUM better by not having such a
sharp distinction between aggressive and non-aggressive VACUUM. Why
should they be so different? A good medium term goal might be to
completely eliminate aggressive VACUUMs.
I have heard many stories about anti-wraparound/aggressive VACUUMs
where the cure (which suddenly made autovacuum workers
non-cancellable) was worse than the disease (not actually much danger
of wraparound failure). For example:
https://www.joyent.com/blog/manta-postmortem-7-27-2015
Yes, this problem report is from 2015, which is before we even had the
freeze map stuff. I still think that the point about aggressive
VACUUMs blocking DDL (leading to chaos) remains valid.
There is another interesting area of future optimization within
VACUUM, that also seems relevant to this patch: the general idea of
*avoiding* pruning during VACUUM, when it just doesn't make sense to
do so -- better to avoid dirtying the page for now. Needlessly pruning
inside lazy_scan_prune is hardly rare -- standard pgbench (maybe only
with heap fill factor reduced to 95) will have autovacuums that
*constantly* do it (granted, it may not matter so much there because
VACUUM is unlikely to re-dirty the page anyway). This patch seems
relevant to that area because it recognizes that pruning during VACUUM
is not necessarily special -- a new function called lazy_scan_noprune
may be used instead of lazy_scan_prune (though only when a cleanup
lock cannot be acquired). These pages are nevertheless considered
fully processed by VACUUM (this is perhaps 99% true, so it seems
reasonable to round up to 100% true).
I find it easy to imagine generalizing the same basic idea --
recognizing more ways in which pruning by VACUUM isn't necessarily
better than opportunistic pruning, at the level of each heap page. Of
course we *need* to prune sometimes (e.g., might be necessary to do so
to set the page all-visible in the visibility map), but why bother
when we don't, and when there is no reason to think that it'll help
anyway? Something to think about, at least.
--
Peter Geoghegan
Attachments:
[application/octet-stream] v1-0002-Improve-log_autovacuum_min_duration-output.patch (7.1K, ../../CAH2-Wznp=c=Opj8Z7RMR3G=ec3_JfGYMN_YvmCEjoPCHzWbx0g@mail.gmail.com/2-v1-0002-Improve-log_autovacuum_min_duration-output.patch)
download | inline diff:
From 9bd19c1e324c0a796091dce988831b1165f815e8 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Sun, 21 Nov 2021 14:47:11 -0800
Subject: [PATCH v1 2/2] Improve log_autovacuum_min_duration output.
Report on visibility map pages skipped by VACUUM, without regard for
whether the pages were all-frozen or just all-visible.
Also report when and how relfrozenxid is advanced by VACUUM, including
non-aggressive VACUUM. Apart from being useful on its own, this might
enable future work that teaches non-aggressive VACUUM to be more
concerned about advancing relfrozenxid sooner rather than later.
---
src/include/commands/vacuum.h | 2 ++
src/backend/access/heap/vacuumlazy.c | 41 ++++++++++++++++++++++------
src/backend/commands/analyze.c | 3 ++
src/backend/commands/vacuum.c | 9 ++++++
4 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index 4cfd52eaf..bc625463e 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -263,6 +263,8 @@ extern void vac_update_relstats(Relation relation,
bool hasindex,
TransactionId frozenxid,
MultiXactId minmulti,
+ bool *frozenxid_updated,
+ bool *minmulti_updated,
bool in_outer_xact);
extern void vacuum_set_xid_limits(Relation rel,
int freeze_min_age, int freeze_table_age,
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 809f59c73..2d23f35a4 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -498,6 +498,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
double read_rate,
write_rate;
bool aggressive;
+ bool frozenxid_updated,
+ minmulti_updated;
BlockNumber orig_rel_pages;
char **indnames = NULL;
TransactionId xidFullScanLimit;
@@ -703,9 +705,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
/* Cannot advance relfrozenxid/relminmxid -- just update pg_class */
Assert(!aggressive);
+ frozenxid_updated = minmulti_updated = false;
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
new_rel_allvisible, vacrel->nindexes > 0,
- InvalidTransactionId, InvalidMultiXactId, false);
+ InvalidTransactionId, InvalidMultiXactId,
+ NULL, NULL, false);
}
else
{
@@ -714,7 +718,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
orig_rel_pages);
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
new_rel_allvisible, vacrel->nindexes > 0,
- FreezeLimit, MultiXactCutoff, false);
+ FreezeLimit, MultiXactCutoff,
+ &frozenxid_updated, &minmulti_updated, false);
}
/*
@@ -744,6 +749,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
StringInfoData buf;
char *msgfmt;
+ int32 diff;
TimestampDifference(starttime, endtime, &secs, &usecs);
@@ -790,16 +796,35 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->relnamespace,
vacrel->relname,
vacrel->num_index_scans);
- appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped frozen\n"),
+ appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped using visibility map (%.2f%% of total)\n"),
vacrel->pages_removed,
vacrel->rel_pages,
- vacrel->frozenskipped_pages);
+ orig_rel_pages - vacrel->scanned_pages,
+ orig_rel_pages > 0 ?
+ 100.0 * (orig_rel_pages - vacrel->scanned_pages) / orig_rel_pages : 0);
appendStringInfo(&buf,
- _("tuples: %lld removed, %lld remain, %lld are dead but not yet removable, oldest xmin: %u\n"),
+ _("tuples: %lld removed, %lld remain, %lld are dead but not yet removable\n"),
(long long) vacrel->tuples_deleted,
(long long) vacrel->new_rel_tuples,
- (long long) vacrel->new_dead_tuples,
- OldestXmin);
+ (long long) vacrel->new_dead_tuples);
+ diff = (int32) (ReadNextTransactionId() - OldestXmin);
+ appendStringInfo(&buf,
+ _("removal cutoff: oldest xmin was %u, which is now %d xact IDs behind\n"),
+ OldestXmin, diff);
+ if (frozenxid_updated)
+ {
+ diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
+ appendStringInfo(&buf,
+ _("relfrozenxid: advanced by %d xact IDs, new value: %u\n"),
+ diff, FreezeLimit);
+ }
+ if (minmulti_updated)
+ {
+ diff = (int32) (MultiXactCutoff - vacrel->relminmxid);
+ appendStringInfo(&buf,
+ _("relminmxid: advanced by %d multixact IDs, new value: %u\n"),
+ diff, MultiXactCutoff);
+ }
if (orig_rel_pages > 0)
{
if (vacrel->do_index_vacuuming)
@@ -4011,7 +4036,7 @@ update_index_statistics(LVRelState *vacrel)
false,
InvalidTransactionId,
InvalidMultiXactId,
- false);
+ NULL, NULL, false);
}
}
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 4928702ae..719bf556a 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -650,6 +650,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
hasindex,
InvalidTransactionId,
InvalidMultiXactId,
+ NULL, NULL,
in_outer_xact);
/* Same for indexes */
@@ -666,6 +667,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
false,
InvalidTransactionId,
InvalidMultiXactId,
+ NULL, NULL,
in_outer_xact);
}
}
@@ -678,6 +680,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
vac_update_relstats(onerel, -1, totalrows,
0, hasindex, InvalidTransactionId,
InvalidMultiXactId,
+ NULL, NULL,
in_outer_xact);
}
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 5c4bc15b4..8bd4bd12c 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -1308,6 +1308,7 @@ vac_update_relstats(Relation relation,
BlockNumber num_all_visible_pages,
bool hasindex, TransactionId frozenxid,
MultiXactId minmulti,
+ bool *frozenxid_updated, bool *minmulti_updated,
bool in_outer_xact)
{
Oid relid = RelationGetRelid(relation);
@@ -1383,22 +1384,30 @@ vac_update_relstats(Relation relation,
* This should match vac_update_datfrozenxid() concerning what we consider
* to be "in the future".
*/
+ if (frozenxid_updated)
+ *frozenxid_updated = false;
if (TransactionIdIsNormal(frozenxid) &&
pgcform->relfrozenxid != frozenxid &&
(TransactionIdPrecedes(pgcform->relfrozenxid, frozenxid) ||
TransactionIdPrecedes(ReadNextTransactionId(),
pgcform->relfrozenxid)))
{
+ if (frozenxid_updated)
+ *frozenxid_updated = true;
pgcform->relfrozenxid = frozenxid;
dirty = true;
}
/* Similarly for relminmxid */
+ if (minmulti_updated)
+ *minmulti_updated = false;
if (MultiXactIdIsValid(minmulti) &&
pgcform->relminmxid != minmulti &&
(MultiXactIdPrecedes(pgcform->relminmxid, minmulti) ||
MultiXactIdPrecedes(ReadNextMultiXactId(), pgcform->relminmxid)))
{
+ if (minmulti_updated)
+ *minmulti_updated = true;
pgcform->relminmxid = minmulti;
dirty = true;
}
--
2.30.2
[application/octet-stream] v1-0001-Simplify-lazy_scan_heap-s-handling-of-scanned-pag.patch (44.1K, ../../CAH2-Wznp=c=Opj8Z7RMR3G=ec3_JfGYMN_YvmCEjoPCHzWbx0g@mail.gmail.com/3-v1-0001-Simplify-lazy_scan_heap-s-handling-of-scanned-pag.patch)
download | inline diff:
From c5698dc01952e09bd922c120ec691e63f9b890c9 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Wed, 17 Nov 2021 21:27:06 -0800
Subject: [PATCH v1 1/2] Simplify lazy_scan_heap's handling of scanned pages.
Redefine a scanned page as any heap page that actually gets pinned by
VACUUM's first pass over the heap. Pages counted by scanned_pages are
now the complement of the pages that are skipped over using the
visibility map. This new definition significantly simplifies quite a
few things.
Now heap relation truncation, visibility map bit setting, tuple counting
(e.g., for pg_class.reltuples), and tuple freezing all share a common
definition of scanned_pages. That makes it possible to remove certain
special cases, that never made much sense. We no longer need to track
tupcount_pages separately (see bugfix commit 1914c5ea for details),
since we now always count tuples from pages that are scanned_pages. We
also don't need to needlessly distinguish between aggressive and
non-aggressive VACUUM operations when we cannot immediately acquire a
cleanup lock.
Since any VACUUM (not just an aggressive VACUUM) can sometimes advance
relfrozenxid, we now make non-aggressive VACUUMs work just a little
harder in order to make that desirable outcome more likely in practice.
Aggressive VACUUMs have long checked contended pages with only a shared
lock, to avoid needlessly waiting on a cleanup lock (in the common case
where the contended page has no tuples that need to be frozen anyway).
We still don't make non-aggressive VACUUMs wait for a cleanup lock, of
course -- if we did that they'd no longer be non-aggressive. But we now
make the non-aggressive case notice that a failure to acquire a cleanup
lock on one particular heap page does not in itself make it unsafe to
advance relfrozenxid for the whole relation (which is what we usually
see in the aggressive case already).
This new relfrozenxid optimization might not be all that valuable on its
own, but it may still facilitate future work that makes non-aggressive
VACUUMs more conscious of the benefit of advancing relfrozenxid sooner
rather than later. In general it would be useful for non-aggressive
VACUUMs to be "more aggressive" opportunistically (e.g., by waiting for
a cleanup lock once or twice if needed). It would also be generally
useful if aggressive VACUUMs were "less aggressive" opportunistically
(e.g. by being responsive to query cancellations when the risk of
wraparound failure is still very low).
We now also collect LP_DEAD items in the dead_tuples array in the case
where we cannot immediately get a cleanup lock on the buffer. We cannot
prune without a cleanup lock, but opportunistic pruning may well have
left some LP_DEAD items behind in the past -- no reason to miss those.
Only VACUUM can mark these LP_DEAD items LP_UNUSED (no opportunistic
technique is independently capable of cleaning up line pointer bloat),
so we should not squander any opportunity to do that. Commit 8523492d4e
taught VACUUM to set LP_DEAD line pointers to LP_UNUSED while only
holding an exclusive lock (not a cleanup lock), so we can expect to set
existing LP_DEAD items to LP_UNUSED reliably, even when we cannot
acquire our own cleanup lock at either pass over the heap (unless we opt
to skip index vacuuming, which implies that there is no second pass over
the heap).
Note that we no longer report on "pin skipped pages" in VACUUM VERBOSE,
since there is no barely any real practical sense in which we actually
miss doing useful work for these pages. Besides, this information
always seemed to have little practical value, even to Postgres hackers.
---
src/backend/access/heap/vacuumlazy.c | 792 +++++++++++-------
.../isolation/expected/vacuum-reltuples.out | 2 +-
.../isolation/specs/vacuum-reltuples.spec | 7 +-
3 files changed, 500 insertions(+), 301 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 88b9d1f41..809f59c73 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -309,6 +309,8 @@ typedef struct LVRelState
Relation *indrels;
int nindexes;
+ /* Aggressive VACUUM (scan all unfrozen pages)? */
+ bool aggressive;
/* Wraparound failsafe has been triggered? */
bool failsafe_active;
/* Consider index vacuuming bypass optimization? */
@@ -333,6 +335,8 @@ typedef struct LVRelState
/* VACUUM operation's cutoff for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
+ /* Are FreezeLimit/MultiXactCutoff still valid? */
+ bool freeze_cutoffs_valid;
/* Error reporting state */
char *relnamespace;
@@ -347,10 +351,8 @@ typedef struct LVRelState
*/
LVDeadTuples *dead_tuples; /* items to vacuum from indexes */
BlockNumber rel_pages; /* total number of pages */
- BlockNumber scanned_pages; /* number of pages we examined */
- BlockNumber pinskipped_pages; /* # of pages skipped due to a pin */
- BlockNumber frozenskipped_pages; /* # of frozen pages we skipped */
- BlockNumber tupcount_pages; /* pages whose tuples we counted */
+ BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
+ BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber pages_removed; /* pages remove by truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber nonempty_pages; /* actually, last nonempty page + 1 */
@@ -363,6 +365,7 @@ typedef struct LVRelState
/* Instrumentation counters */
int num_index_scans;
+ /* Counters that follow are only for scanned_pages */
int64 tuples_deleted; /* # deleted from table */
int64 lpdead_items; /* # deleted from indexes */
int64 new_dead_tuples; /* new estimated total # of dead items in
@@ -402,19 +405,22 @@ static int elevel = -1;
/* non-export function prototypes */
-static void lazy_scan_heap(LVRelState *vacrel, VacuumParams *params,
- bool aggressive);
+static void lazy_scan_heap(LVRelState *vacrel, VacuumParams *params);
+static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf,
+ BlockNumber blkno, Page page,
+ bool sharelock, Buffer vmbuffer);
static void lazy_scan_prune(LVRelState *vacrel, Buffer buf,
BlockNumber blkno, Page page,
GlobalVisState *vistest,
LVPagePruneState *prunestate);
+static bool lazy_scan_noprune(LVRelState *vacrel, Buffer buf,
+ BlockNumber blkno, Page page,
+ bool *hastup);
static void lazy_vacuum(LVRelState *vacrel);
static bool lazy_vacuum_all_indexes(LVRelState *vacrel);
static void lazy_vacuum_heap_rel(LVRelState *vacrel);
static int lazy_vacuum_heap_page(LVRelState *vacrel, BlockNumber blkno,
Buffer buffer, int tupindex, Buffer *vmbuffer);
-static bool lazy_check_needs_freeze(Buffer buf, bool *hastup,
- LVRelState *vacrel);
static bool lazy_check_wraparound_failsafe(LVRelState *vacrel);
static void do_parallel_lazy_vacuum_all_indexes(LVRelState *vacrel);
static void do_parallel_lazy_cleanup_all_indexes(LVRelState *vacrel);
@@ -491,16 +497,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
int usecs;
double read_rate,
write_rate;
- bool aggressive; /* should we scan all unfrozen pages? */
- bool scanned_all_unfrozen; /* actually scanned all such pages? */
+ bool aggressive;
+ BlockNumber orig_rel_pages;
char **indnames = NULL;
TransactionId xidFullScanLimit;
MultiXactId mxactFullScanLimit;
BlockNumber new_rel_pages;
BlockNumber new_rel_allvisible;
double new_live_tuples;
- TransactionId new_frozen_xid;
- MultiXactId new_min_multi;
ErrorContextCallback errcallback;
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
@@ -555,6 +559,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->rel = rel;
vac_open_indexes(vacrel->rel, RowExclusiveLock, &vacrel->nindexes,
&vacrel->indrels);
+ vacrel->aggressive = aggressive;
vacrel->failsafe_active = false;
vacrel->consider_bypass_optimization = true;
@@ -599,6 +604,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->OldestXmin = OldestXmin;
vacrel->FreezeLimit = FreezeLimit;
vacrel->MultiXactCutoff = MultiXactCutoff;
+ /* Track if cutoffs became invalid (possible in !aggressive case only) */
+ vacrel->freeze_cutoffs_valid = true;
vacrel->relnamespace = get_namespace_name(RelationGetNamespace(rel));
vacrel->relname = pstrdup(RelationGetRelationName(rel));
@@ -632,30 +639,16 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
error_context_stack = &errcallback;
/* Do the vacuuming */
- lazy_scan_heap(vacrel, params, aggressive);
+ lazy_scan_heap(vacrel, params);
/* Done with indexes */
vac_close_indexes(vacrel->nindexes, vacrel->indrels, NoLock);
/*
- * Compute whether we actually scanned the all unfrozen pages. If we did,
- * we can adjust relfrozenxid and relminmxid.
- *
- * NB: We need to check this before truncating the relation, because that
- * will change ->rel_pages.
- */
- if ((vacrel->scanned_pages + vacrel->frozenskipped_pages)
- < vacrel->rel_pages)
- {
- Assert(!aggressive);
- scanned_all_unfrozen = false;
- }
- else
- scanned_all_unfrozen = true;
-
- /*
- * Optionally truncate the relation.
+ * Optionally truncate the relation. But remember the relation size used
+ * by lazy_scan_prune for later first.
*/
+ orig_rel_pages = vacrel->rel_pages;
if (should_attempt_truncation(vacrel))
{
/*
@@ -686,28 +679,43 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
*
* For safety, clamp relallvisible to be not more than what we're setting
* relpages to.
- *
- * Also, don't change relfrozenxid/relminmxid if we skipped any pages,
- * since then we don't know for certain that all tuples have a newer xmin.
*/
- new_rel_pages = vacrel->rel_pages;
+ new_rel_pages = vacrel->rel_pages; /* After possible rel truncation */
new_live_tuples = vacrel->new_live_tuples;
visibilitymap_count(rel, &new_rel_allvisible, NULL);
if (new_rel_allvisible > new_rel_pages)
new_rel_allvisible = new_rel_pages;
- new_frozen_xid = scanned_all_unfrozen ? FreezeLimit : InvalidTransactionId;
- new_min_multi = scanned_all_unfrozen ? MultiXactCutoff : InvalidMultiXactId;
-
- vac_update_relstats(rel,
- new_rel_pages,
- new_live_tuples,
- new_rel_allvisible,
- vacrel->nindexes > 0,
- new_frozen_xid,
- new_min_multi,
- false);
+ /*
+ * Aggressive VACUUM (which is the same thing as anti-wraparound
+ * autovacuum for most practical purposes) exists so that we'll reliably
+ * advance relfrozenxid and relminmxid sooner or later. But we can often
+ * opportunistically advance them even in a non-aggressive VACUUM.
+ * Consider if that's possible now.
+ *
+ * NB: We must use orig_rel_pages, not vacrel->rel_pages, since we want
+ * the rel_pages used by lazy_scan_prune, from before a possible relation
+ * truncation took place. (vacrel->rel_pages is now new_rel_pages.)
+ */
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
+ !vacrel->freeze_cutoffs_valid)
+ {
+ /* Cannot advance relfrozenxid/relminmxid -- just update pg_class */
+ Assert(!aggressive);
+ vac_update_relstats(rel, new_rel_pages, new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ InvalidTransactionId, InvalidMultiXactId, false);
+ }
+ else
+ {
+ /* Can safely advance relfrozen and relminmxid, too */
+ Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
+ orig_rel_pages);
+ vac_update_relstats(rel, new_rel_pages, new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ FreezeLimit, MultiXactCutoff, false);
+ }
/*
* Report results to the stats collector, too.
@@ -736,7 +744,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
StringInfoData buf;
char *msgfmt;
- BlockNumber orig_rel_pages;
TimestampDifference(starttime, endtime, &secs, &usecs);
@@ -783,10 +790,9 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->relnamespace,
vacrel->relname,
vacrel->num_index_scans);
- appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped due to pins, %u skipped frozen\n"),
+ appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped frozen\n"),
vacrel->pages_removed,
vacrel->rel_pages,
- vacrel->pinskipped_pages,
vacrel->frozenskipped_pages);
appendStringInfo(&buf,
_("tuples: %lld removed, %lld remain, %lld are dead but not yet removable, oldest xmin: %u\n"),
@@ -794,7 +800,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
(long long) vacrel->new_rel_tuples,
(long long) vacrel->new_dead_tuples,
OldestXmin);
- orig_rel_pages = vacrel->rel_pages + vacrel->pages_removed;
if (orig_rel_pages > 0)
{
if (vacrel->do_index_vacuuming)
@@ -891,9 +896,10 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* reference them have been killed.
*/
static void
-lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
+lazy_scan_heap(LVRelState *vacrel, VacuumParams *params)
{
LVDeadTuples *dead_tuples;
+ bool aggressive;
BlockNumber nblocks,
blkno,
next_unskippable_block,
@@ -913,26 +919,14 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pg_rusage_init(&ru0);
- if (aggressive)
- ereport(elevel,
- (errmsg("aggressively vacuuming \"%s.%s\"",
- vacrel->relnamespace,
- vacrel->relname)));
- else
- ereport(elevel,
- (errmsg("vacuuming \"%s.%s\"",
- vacrel->relnamespace,
- vacrel->relname)));
-
+ aggressive = vacrel->aggressive;
nblocks = RelationGetNumberOfBlocks(vacrel->rel);
next_unskippable_block = 0;
next_failsafe_block = 0;
next_fsm_block_to_vacuum = 0;
vacrel->rel_pages = nblocks;
vacrel->scanned_pages = 0;
- vacrel->pinskipped_pages = 0;
vacrel->frozenskipped_pages = 0;
- vacrel->tupcount_pages = 0;
vacrel->pages_removed = 0;
vacrel->lpdead_item_pages = 0;
vacrel->nonempty_pages = 0;
@@ -950,6 +944,17 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
vacrel->indstats = (IndexBulkDeleteResult **)
palloc0(vacrel->nindexes * sizeof(IndexBulkDeleteResult *));
+ if (aggressive)
+ ereport(elevel,
+ (errmsg("aggressively vacuuming \"%s.%s\"",
+ vacrel->relnamespace,
+ vacrel->relname)));
+ else
+ ereport(elevel,
+ (errmsg("vacuuming \"%s.%s\"",
+ vacrel->relnamespace,
+ vacrel->relname)));
+
/*
* Before beginning scan, check if it's already necessary to apply
* failsafe
@@ -1004,15 +1009,6 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* just added to that page are necessarily newer than the GlobalXmin we
* computed, so they'll have no effect on the value to which we can safely
* set relfrozenxid. A similar argument applies for MXIDs and relminmxid.
- *
- * We will scan the table's last page, at least to the extent of
- * determining whether it has tuples or not, even if it should be skipped
- * according to the above rules; except when we've already determined that
- * it's not worth trying to truncate the table. This avoids having
- * lazy_truncate_heap() take access-exclusive lock on the table to attempt
- * a truncation that just fails immediately because there are tuples in
- * the last page. This is worth avoiding mainly because such a lock must
- * be replayed on any hot standby, where it can be disruptive.
*/
if ((params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0)
{
@@ -1050,18 +1046,14 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
bool all_visible_according_to_vm = false;
LVPagePruneState prunestate;
- /*
- * Consider need to skip blocks. See note above about forcing
- * scanning of last page.
- */
-#define FORCE_CHECK_PAGE() \
- (blkno == nblocks - 1 && should_attempt_truncation(vacrel))
-
pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
blkno, InvalidOffsetNumber);
+ /*
+ * Consider need to skip blocks
+ */
if (blkno == next_unskippable_block)
{
/* Time to advance next_unskippable_block */
@@ -1110,13 +1102,19 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
else
{
/*
- * The current block is potentially skippable; if we've seen a
- * long enough run of skippable blocks to justify skipping it, and
- * we're not forced to check it, then go ahead and skip.
- * Otherwise, the page must be at least all-visible if not
- * all-frozen, so we can set all_visible_according_to_vm = true.
+ * The current block can be skipped if we've seen a long enough
+ * run of skippable blocks to justify skipping it.
+ *
+ * There is an exception: we will scan the table's last page to
+ * determine whether it has tuples or not, even if it would
+ * otherwise be skipped (unless it's clearly not worth trying to
+ * truncate the table). This avoids having lazy_truncate_heap()
+ * take access-exclusive lock on the table to attempt a truncation
+ * that just fails immediately because there are tuples in the
+ * last page.
*/
- if (skipping_blocks && !FORCE_CHECK_PAGE())
+ if (skipping_blocks &&
+ !(blkno == nblocks - 1 && should_attempt_truncation(vacrel)))
{
/*
* Tricky, tricky. If this is in aggressive vacuum, the page
@@ -1126,12 +1124,22 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* case, or else we'll think we can't update relfrozenxid and
* relminmxid. If it's not an aggressive vacuum, we don't
* know whether it was all-frozen, so we have to recheck; but
- * in this case an approximate answer is OK.
+ * in this case an approximate answer is still correct.
+ *
+ * (We really don't want to miss out on the opportunity to
+ * advance relfrozenxid in a non-aggressive vacuum, but this
+ * edge case shouldn't make that appreciably less likely in
+ * practice.)
*/
if (aggressive || VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
vacrel->frozenskipped_pages++;
continue;
}
+
+ /*
+ * Otherwise, the page must be at least all-visible if not
+ * all-frozen, so we can set all_visible_according_to_vm = true
+ */
all_visible_according_to_vm = true;
}
@@ -1156,7 +1164,8 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* Consider if we definitely have enough space to process TIDs on page
* already. If we are close to overrunning the available space for
* dead-tuple TIDs, pause and do a cycle of vacuuming before we tackle
- * this page.
+ * this page. Must do this before calling lazy_scan_prune (or before
+ * calling lazy_scan_noprune).
*/
if ((dead_tuples->max_tuples - dead_tuples->num_tuples) < MaxHeapTuplesPerPage &&
dead_tuples->num_tuples > 0)
@@ -1191,7 +1200,8 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
}
/*
- * Set up visibility map page as needed.
+ * Set up visibility map page as needed, and pin the heap page that
+ * we're going to scan.
*
* Pin the visibility map page in case we need to mark the page
* all-visible. In most cases this will be very cheap, because we'll
@@ -1204,156 +1214,52 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
buf = ReadBufferExtended(vacrel->rel, MAIN_FORKNUM, blkno,
RBM_NORMAL, vacrel->bstrategy);
+ page = BufferGetPage(buf);
+ vacrel->scanned_pages++;
/*
- * We need buffer cleanup lock so that we can prune HOT chains and
- * defragment the page.
+ * We need a buffer cleanup lock to prune HOT chains and defragment
+ * the page in lazy_scan_prune. But when it's not possible to acquire
+ * a cleanup lock right away, we may be able to settle for reduced
+ * processing in lazy_scan_noprune.
*/
if (!ConditionalLockBufferForCleanup(buf))
{
bool hastup;
- /*
- * If we're not performing an aggressive scan to guard against XID
- * wraparound, and we don't want to forcibly check the page, then
- * it's OK to skip vacuuming pages we get a lock conflict on. They
- * will be dealt with in some future vacuum.
- */
- if (!aggressive && !FORCE_CHECK_PAGE())
+ LockBuffer(buf, BUFFER_LOCK_SHARE);
+
+ /* Check for new or empty pages before lazy_scan_noprune call */
+ if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, true,
+ vmbuffer))
{
- ReleaseBuffer(buf);
- vacrel->pinskipped_pages++;
+ /* Lock and pin released for us */
+ continue;
+ }
+
+ if (lazy_scan_noprune(vacrel, buf, blkno, page, &hastup))
+ {
+ /* No need to wait for cleanup lock for this page */
+ UnlockReleaseBuffer(buf);
+ if (hastup)
+ vacrel->nonempty_pages = blkno + 1;
continue;
}
/*
- * Read the page with share lock to see if any xids on it need to
- * be frozen. If not we just skip the page, after updating our
- * scan statistics. If there are some, we wait for cleanup lock.
- *
- * We could defer the lock request further by remembering the page
- * and coming back to it later, or we could even register
- * ourselves for multiple buffers and then service whichever one
- * is received first. For now, this seems good enough.
- *
- * If we get here with aggressive false, then we're just forcibly
- * checking the page, and so we don't want to insist on getting
- * the lock; we only need to know if the page contains tuples, so
- * that we can update nonempty_pages correctly. It's convenient
- * to use lazy_check_needs_freeze() for both situations, though.
+ * lazy_scan_noprune could not do all required processing without
+ * a cleanup lock. Wait for a cleanup lock, and then proceed to
+ * lazy_scan_prune to perform ordinary pruning and freezing.
*/
- LockBuffer(buf, BUFFER_LOCK_SHARE);
- if (!lazy_check_needs_freeze(buf, &hastup, vacrel))
- {
- UnlockReleaseBuffer(buf);
- vacrel->scanned_pages++;
- vacrel->pinskipped_pages++;
- if (hastup)
- vacrel->nonempty_pages = blkno + 1;
- continue;
- }
- if (!aggressive)
- {
- /*
- * Here, we must not advance scanned_pages; that would amount
- * to claiming that the page contains no freezable tuples.
- */
- UnlockReleaseBuffer(buf);
- vacrel->pinskipped_pages++;
- if (hastup)
- vacrel->nonempty_pages = blkno + 1;
- continue;
- }
+ Assert(vacrel->aggressive);
LockBuffer(buf, BUFFER_LOCK_UNLOCK);
LockBufferForCleanup(buf);
- /* drop through to normal processing */
}
- /*
- * By here we definitely have enough dead_tuples space for whatever
- * LP_DEAD tids are on this page, we have the visibility map page set
- * up in case we need to set this page's all_visible/all_frozen bit,
- * and we have a super-exclusive lock. Any tuples on this page are
- * now sure to be "counted" by this VACUUM.
- *
- * One last piece of preamble needs to take place before we can prune:
- * we need to consider new and empty pages.
- */
- vacrel->scanned_pages++;
- vacrel->tupcount_pages++;
-
- page = BufferGetPage(buf);
-
- if (PageIsNew(page))
+ /* Check for new or empty pages before lazy_scan_prune call */
+ if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, false, vmbuffer))
{
- /*
- * All-zeroes pages can be left over if either a backend extends
- * the relation by a single page, but crashes before the newly
- * initialized page has been written out, or when bulk-extending
- * the relation (which creates a number of empty pages at the tail
- * end of the relation, but enters them into the FSM).
- *
- * Note we do not enter the page into the visibilitymap. That has
- * the downside that we repeatedly visit this page in subsequent
- * vacuums, but otherwise we'll never not discover the space on a
- * promoted standby. The harm of repeated checking ought to
- * normally not be too bad - the space usually should be used at
- * some point, otherwise there wouldn't be any regular vacuums.
- *
- * Make sure these pages are in the FSM, to ensure they can be
- * reused. Do that by testing if there's any space recorded for
- * the page. If not, enter it. We do so after releasing the lock
- * on the heap page, the FSM is approximate, after all.
- */
- UnlockReleaseBuffer(buf);
-
- if (GetRecordedFreeSpace(vacrel->rel, blkno) == 0)
- {
- Size freespace = BLCKSZ - SizeOfPageHeaderData;
-
- RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
- }
- continue;
- }
-
- if (PageIsEmpty(page))
- {
- Size freespace = PageGetHeapFreeSpace(page);
-
- /*
- * Empty pages are always all-visible and all-frozen (note that
- * the same is currently not true for new pages, see above).
- */
- if (!PageIsAllVisible(page))
- {
- START_CRIT_SECTION();
-
- /* mark buffer dirty before writing a WAL record */
- MarkBufferDirty(buf);
-
- /*
- * It's possible that another backend has extended the heap,
- * initialized the page, and then failed to WAL-log the page
- * due to an ERROR. Since heap extension is not WAL-logged,
- * recovery might try to replay our record setting the page
- * all-visible and find that the page isn't initialized, which
- * will cause a PANIC. To prevent that, check whether the
- * page has been previously WAL-logged, and if not, do that
- * now.
- */
- if (RelationNeedsWAL(vacrel->rel) &&
- PageGetLSN(page) == InvalidXLogRecPtr)
- log_newpage_buffer(buf, true);
-
- PageSetAllVisible(page);
- visibilitymap_set(vacrel->rel, blkno, buf, InvalidXLogRecPtr,
- vmbuffer, InvalidTransactionId,
- VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
- END_CRIT_SECTION();
- }
-
- UnlockReleaseBuffer(buf);
- RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ /* Lock and pin released for us */
continue;
}
@@ -1566,7 +1472,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
/* now we can compute the new value for pg_class.reltuples */
vacrel->new_live_tuples = vac_estimate_reltuples(vacrel->rel, nblocks,
- vacrel->tupcount_pages,
+ vacrel->scanned_pages,
vacrel->live_tuples);
/*
@@ -1640,14 +1546,10 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
appendStringInfo(&buf,
_("%lld dead row versions cannot be removed yet, oldest xmin: %u\n"),
(long long) vacrel->new_dead_tuples, vacrel->OldestXmin);
- appendStringInfo(&buf, ngettext("Skipped %u page due to buffer pins, ",
- "Skipped %u pages due to buffer pins, ",
- vacrel->pinskipped_pages),
- vacrel->pinskipped_pages);
- appendStringInfo(&buf, ngettext("%u frozen page.\n",
- "%u frozen pages.\n",
- vacrel->frozenskipped_pages),
- vacrel->frozenskipped_pages);
+ appendStringInfo(&buf, ngettext("%u page skipped using visibility map.\n",
+ "%u pages skipped using visibility map.\n",
+ vacrel->rel_pages - vacrel->scanned_pages),
+ vacrel->rel_pages - vacrel->scanned_pages);
appendStringInfo(&buf, _("%s."), pg_rusage_show(&ru0));
ereport(elevel,
@@ -1661,6 +1563,132 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pfree(buf.data);
}
+/*
+ * lazy_scan_new_or_empty() -- lazy_scan_heap() new/empty page handling.
+ *
+ * Must call here to handle both new and empty pages before calling
+ * lazy_scan_prune or lazy_scan_noprune, since they're not prepared to deal
+ * with new or empty pages.
+ *
+ * It's necessary to consider new pages as a special case, since the rules for
+ * maintaining the visibility map and FSM with empty pages are a little
+ * different (though new pages can be truncated based on the usual rules).
+ *
+ * Empty pages are not really a special case -- they're just heap pages that
+ * have no allocated tuples (including even LP_UNUSED items). You might
+ * wonder why we need to handle them here all the same. It's only necessary
+ * because of a rare corner-case involving a hard crash during heap relation
+ * extension. If we ever make relation-extension crash safe, then it should
+ * no longer be necessary to deal with empty pages here (or new pages, for
+ * that matter).
+ *
+ * Caller can either hold a buffer cleanup lock on the buffer, or a simple
+ * shared lock.
+ */
+static bool
+lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf, BlockNumber blkno,
+ Page page, bool sharelock, Buffer vmbuffer)
+{
+ Size freespace;
+
+ if (PageIsNew(page))
+ {
+ /*
+ * All-zeroes pages can be left over if either a backend extends the
+ * relation by a single page, but crashes before the newly initialized
+ * page has been written out, or when bulk-extending the relation
+ * (which creates a number of empty pages at the tail end of the
+ * relation), and then enters them into the FSM.
+ *
+ * Note we do not enter the page into the visibilitymap. That has the
+ * downside that we repeatedly visit this page in subsequent vacuums,
+ * but otherwise we'll never not discover the space on a promoted
+ * standby. The harm of repeated checking ought to normally not be too
+ * bad - the space usually should be used at some point, otherwise
+ * there wouldn't be any regular vacuums.
+ *
+ * Make sure these pages are in the FSM, to ensure they can be reused.
+ * Do that by testing if there's any space recorded for the page. If
+ * not, enter it. We do so after releasing the lock on the heap page,
+ * the FSM is approximate, after all.
+ */
+ UnlockReleaseBuffer(buf);
+
+ if (GetRecordedFreeSpace(vacrel->rel, blkno) == 0)
+ {
+ freespace = BLCKSZ - SizeOfPageHeaderData;
+
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ }
+
+ return true;
+ }
+
+ if (PageIsEmpty(page))
+ {
+ /*
+ * It seems likely that caller will always be able to get a cleanup
+ * lock on an empty page. But don't take any chances -- escalate to
+ * an exclusive lock (still don't need a cleanup lock, though).
+ */
+ if (sharelock)
+ {
+ LockBuffer(buf, BUFFER_LOCK_UNLOCK);
+ LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
+
+ if (!PageIsEmpty(page))
+ {
+ /* page isn't new or empty -- keep lock and pin for now */
+ return false;
+ }
+ }
+ else
+ {
+ /* Already have a full cleanup lock (which is more than enough) */
+ }
+
+ freespace = PageGetHeapFreeSpace(page);
+
+ /*
+ * Unlike new pages, empty pages are always set all-visible and
+ * all-frozen.
+ */
+ if (!PageIsAllVisible(page))
+ {
+ START_CRIT_SECTION();
+
+ /* mark buffer dirty before writing a WAL record */
+ MarkBufferDirty(buf);
+
+ /*
+ * It's possible that another backend has extended the heap,
+ * initialized the page, and then failed to WAL-log the page due
+ * to an ERROR. Since heap extension is not WAL-logged, recovery
+ * might try to replay our record setting the page all-visible and
+ * find that the page isn't initialized, which will cause a PANIC.
+ * To prevent that, check whether the page has been previously
+ * WAL-logged, and if not, do that now.
+ */
+ if (RelationNeedsWAL(vacrel->rel) &&
+ PageGetLSN(page) == InvalidXLogRecPtr)
+ log_newpage_buffer(buf, true);
+
+ PageSetAllVisible(page);
+ visibilitymap_set(vacrel->rel, blkno, buf, InvalidXLogRecPtr,
+ vmbuffer, InvalidTransactionId,
+ VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
+ END_CRIT_SECTION();
+ }
+
+ UnlockReleaseBuffer(buf);
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ return true;
+ }
+
+ /* page isn't new or empty -- keep lock and pin */
+ return false;
+}
+
/*
* lazy_scan_prune() -- lazy_scan_heap() pruning and freezing.
*
@@ -1767,10 +1795,9 @@ retry:
* LP_DEAD items are processed outside of the loop.
*
* Note that we deliberately don't set hastup=true in the case of an
- * LP_DEAD item here, which is not how lazy_check_needs_freeze() or
- * count_nondeletable_pages() do it -- they only consider pages empty
- * when they only have LP_UNUSED items, which is important for
- * correctness.
+ * LP_DEAD item here, which is not how count_nondeletable_pages() does
+ * it -- it only considers pages empty/truncatable when they have no
+ * items at all (except LP_UNUSED items).
*
* Our assumption is that any LP_DEAD items we encounter here will
* become LP_UNUSED inside lazy_vacuum_heap_page() before we actually
@@ -2057,6 +2084,236 @@ retry:
vacrel->live_tuples += live_tuples;
}
+/*
+ * lazy_scan_noprune() -- lazy_scan_prune() variant without pruning
+ *
+ * Caller need only hold a pin and share lock on the buffer, unlike
+ * lazy_scan_prune, which requires a full cleanup lock.
+ *
+ * While pruning isn't performed here, we can at least collect existing
+ * LP_DEAD items into the dead_tuples array for removal from indexes. It's
+ * quite possible that earlier opportunistic pruning left LP_DEAD items
+ * behind, and we shouldn't miss out on an opportunity to make them reusable
+ * (VACUUM alone is capable of cleaning up line pointer bloat like this).
+ * Note that we'll only require an exclusive lock (not a cleanup lock) later
+ * on when we set these LP_DEAD items to LP_UNUSED in lazy_vacuum_heap_page.
+ *
+ * Freezing isn't performed here either. For aggressive VACUUM callers, we
+ * may return false to indicate that a full cleanup lock is required. This is
+ * necessary because pruning requires a cleanup lock, and because VACUUM
+ * cannot freeze a page's tuples until after pruning takes place (freezing
+ * tuples effectively requires a cleanup lock, though we don't need a cleanup
+ * lock in lazy_vacuum_heap_page or in lazy_scan_new_or_empty to set a heap
+ * page all-frozen in the visibility map).
+ *
+ * We'll always return true for a non-aggressive VACUUM, even when we know
+ * that this will cause them to miss out on freezing tuples from before
+ * vacrel->FreezeLimit cutoff -- they should never have to wait for a cleanup
+ * lock. This does mean that they definitely won't be able to advance
+ * relfrozenxid opportunistically (same applies to vacrel->MultiXactCutoff and
+ * relminmxid).
+ *
+ * See lazy_scan_prune for an explanation of hastup return flag.
+ */
+static bool
+lazy_scan_noprune(LVRelState *vacrel,
+ Buffer buf,
+ BlockNumber blkno,
+ Page page,
+ bool *hastup)
+{
+ OffsetNumber offnum,
+ maxoff;
+ bool has_tuple_needs_freeze = false;
+ int lpdead_items,
+ num_tuples,
+ live_tuples,
+ new_dead_tuples;
+ HeapTupleHeader tupleheader;
+ OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
+
+ *hastup = false; /* for now */
+
+ lpdead_items = 0;
+ num_tuples = 0;
+ live_tuples = 0;
+ new_dead_tuples = 0;
+
+ maxoff = PageGetMaxOffsetNumber(page);
+ for (offnum = FirstOffsetNumber;
+ offnum <= maxoff;
+ offnum = OffsetNumberNext(offnum))
+ {
+ ItemId itemid;
+ HeapTupleData tuple;
+
+ vacrel->offnum = offnum;
+ itemid = PageGetItemId(page, offnum);
+
+ if (!ItemIdIsUsed(itemid))
+ continue;
+
+ if (ItemIdIsRedirected(itemid))
+ {
+ *hastup = true; /* page won't be truncatable */
+ continue;
+ }
+
+ if (ItemIdIsDead(itemid))
+ {
+ /*
+ * Deliberately don't set hastup=true here. See same point in
+ * lazy_scan_prune for an explanation.
+ */
+ deadoffsets[lpdead_items++] = offnum;
+ continue;
+ }
+
+ tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
+ if (!has_tuple_needs_freeze &&
+ heap_tuple_needs_freeze(tupleheader, vacrel->FreezeLimit,
+ vacrel->MultiXactCutoff, buf))
+ {
+ if (vacrel->aggressive)
+ {
+ /* Going to have to get cleanup lock for lazy_scan_prune */
+ vacrel->offnum = InvalidOffsetNumber;
+ return false;
+ }
+
+ has_tuple_needs_freeze = true;
+ }
+
+ num_tuples++;
+ ItemPointerSet(&(tuple.t_self), blkno, offnum);
+ tuple.t_data = (HeapTupleHeader) PageGetItem(page, itemid);
+ tuple.t_len = ItemIdGetLength(itemid);
+ tuple.t_tableOid = RelationGetRelid(vacrel->rel);
+
+ switch (HeapTupleSatisfiesVacuum(&tuple, vacrel->OldestXmin, buf))
+ {
+ case HEAPTUPLE_DELETE_IN_PROGRESS:
+ case HEAPTUPLE_LIVE:
+
+ /*
+ * Count both cases as live, just like lazy_scan_prune
+ */
+ live_tuples++;
+
+ break;
+ case HEAPTUPLE_DEAD:
+ case HEAPTUPLE_RECENTLY_DEAD:
+
+ /*
+ * We count DEAD and RECENTLY_DEAD tuples in new_dead_tuples.
+ *
+ * lazy_scan_prune only does this for RECENTLY_DEAD tuples,
+ * and never has to deal with DEAD tuples directly (they
+ * reliably become LP_DEAD items through pruning). Our
+ * approach to DEAD tuples is a bit arbitrary, but it seems
+ * better than totally ignoring them.
+ */
+ new_dead_tuples++;
+ break;
+ case HEAPTUPLE_INSERT_IN_PROGRESS:
+
+ /*
+ * Do not count these rows as live, just like lazy_scan_prune
+ */
+ break;
+ default:
+ elog(ERROR, "unexpected HeapTupleSatisfiesVacuum result");
+ break;
+ }
+
+ }
+
+ vacrel->offnum = InvalidOffsetNumber;
+
+ if (has_tuple_needs_freeze)
+ {
+ /*
+ * Current non-aggressive VACUUM operation definitely won't be able to
+ * advance relfrozenxid or relminmxid
+ */
+ Assert(!vacrel->aggressive);
+ vacrel->freeze_cutoffs_valid = false;
+ }
+
+ /*
+ * Now save details of the LP_DEAD items from the page in the dead_tuples
+ * array iff VACUUM uses two-pass strategy case
+ */
+ if (vacrel->nindexes == 0)
+ {
+ /*
+ * We are not prepared to handle the corner case where a single pass
+ * strategy VACUUM cannot get a cleanup lock, and we then find LP_DEAD
+ * items. Repeat the same trick that we use for DEAD tuples: pretend
+ * that they're RECENTLY_DEAD tuples.
+ *
+ * There is no fundamental reason why we must take the easy way out
+ * like this. Finding a way to make these LP_DEAD items get set to
+ * LP_UNUSED would be less valuable and more complicated than it is in
+ * the two-pass strategy case, since it would necessitate that we
+ * repeat our lazy_scan_heap caller's page-at-a-time/one-pass-strategy
+ * heap vacuuming steps. Whereas in the two-pass strategy case,
+ * lazy_vacuum_heap_rel will set the LP_DEAD items to LP_UNUSED. It
+ * must always deal with things like remaining DEAD tuples with
+ * storage, new LP_DEAD items that we didn't see earlier on, etc.
+ */
+ if (lpdead_items > 0)
+ *hastup = true; /* page won't be truncatable */
+ num_tuples += lpdead_items;
+ new_dead_tuples += lpdead_items;
+ }
+ else if (lpdead_items > 0)
+ {
+ LVDeadTuples *dead_tuples = vacrel->dead_tuples;
+ ItemPointerData tmp;
+
+ vacrel->lpdead_item_pages++;
+
+ ItemPointerSetBlockNumber(&tmp, blkno);
+
+ for (int i = 0; i < lpdead_items; i++)
+ {
+ ItemPointerSetOffsetNumber(&tmp, deadoffsets[i]);
+ dead_tuples->itemptrs[dead_tuples->num_tuples++] = tmp;
+ }
+
+ Assert(dead_tuples->num_tuples <= dead_tuples->max_tuples);
+ pgstat_progress_update_param(PROGRESS_VACUUM_NUM_DEAD_TUPLES,
+ dead_tuples->num_tuples);
+
+ vacrel->lpdead_items += lpdead_items;
+ }
+ else
+ {
+ /*
+ * We opt to skip FSM processing for the page on the grounds that it
+ * is probably being modified by concurrent DML operations. Seems
+ * best to assume that the space is best left behind for future
+ * updates of existing tuples. This matches what opportunistic
+ * pruning does.
+ *
+ * It's theoretically possible for us to set VM bits here too, but we
+ * don't try that either. It is highly unlikely to be possible, much
+ * less useful.
+ */
+ }
+
+ /*
+ * Finally, add relevant page-local counts to whole-VACUUM counts
+ */
+ vacrel->new_dead_tuples += new_dead_tuples;
+ vacrel->num_tuples += num_tuples;
+ vacrel->live_tuples += live_tuples;
+
+ /* Caller won't need to call lazy_scan_prune with same page */
+ return true;
+}
+
/*
* Remove the collected garbage tuples from the table and its indexes.
*
@@ -2504,67 +2761,6 @@ lazy_vacuum_heap_page(LVRelState *vacrel, BlockNumber blkno, Buffer buffer,
return tupindex;
}
-/*
- * lazy_check_needs_freeze() -- scan page to see if any tuples
- * need to be cleaned to avoid wraparound
- *
- * Returns true if the page needs to be vacuumed using cleanup lock.
- * Also returns a flag indicating whether page contains any tuples at all.
- */
-static bool
-lazy_check_needs_freeze(Buffer buf, bool *hastup, LVRelState *vacrel)
-{
- Page page = BufferGetPage(buf);
- OffsetNumber offnum,
- maxoff;
- HeapTupleHeader tupleheader;
-
- *hastup = false;
-
- /*
- * New and empty pages, obviously, don't contain tuples. We could make
- * sure that the page is registered in the FSM, but it doesn't seem worth
- * waiting for a cleanup lock just for that, especially because it's
- * likely that the pin holder will do so.
- */
- if (PageIsNew(page) || PageIsEmpty(page))
- return false;
-
- maxoff = PageGetMaxOffsetNumber(page);
- for (offnum = FirstOffsetNumber;
- offnum <= maxoff;
- offnum = OffsetNumberNext(offnum))
- {
- ItemId itemid;
-
- /*
- * Set the offset number so that we can display it along with any
- * error that occurred while processing this tuple.
- */
- vacrel->offnum = offnum;
- itemid = PageGetItemId(page, offnum);
-
- /* this should match hastup test in count_nondeletable_pages() */
- if (ItemIdIsUsed(itemid))
- *hastup = true;
-
- /* dead and redirect items never need freezing */
- if (!ItemIdIsNormal(itemid))
- continue;
-
- tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
-
- if (heap_tuple_needs_freeze(tupleheader, vacrel->FreezeLimit,
- vacrel->MultiXactCutoff, buf))
- break;
- } /* scan along page */
-
- /* Clear the offset information once we have processed the given page. */
- vacrel->offnum = InvalidOffsetNumber;
-
- return (offnum <= maxoff);
-}
-
/*
* Trigger the failsafe to avoid wraparound failure when vacrel table has a
* relfrozenxid and/or relminmxid that is dangerously far in the past.
@@ -2659,7 +2855,7 @@ do_parallel_lazy_cleanup_all_indexes(LVRelState *vacrel)
*/
vacrel->lps->lvshared->reltuples = vacrel->new_rel_tuples;
vacrel->lps->lvshared->estimated_count =
- (vacrel->tupcount_pages < vacrel->rel_pages);
+ (vacrel->scanned_pages < vacrel->rel_pages);
/* Determine the number of parallel workers to launch */
if (vacrel->lps->lvshared->first_time)
@@ -2976,7 +3172,7 @@ lazy_cleanup_all_indexes(LVRelState *vacrel)
{
double reltuples = vacrel->new_rel_tuples;
bool estimated_count =
- vacrel->tupcount_pages < vacrel->rel_pages;
+ vacrel->scanned_pages < vacrel->rel_pages;
for (int idx = 0; idx < vacrel->nindexes; idx++)
{
@@ -3124,7 +3320,9 @@ lazy_cleanup_one_index(Relation indrel, IndexBulkDeleteResult *istat,
* should_attempt_truncation - should we attempt to truncate the heap?
*
* Don't even think about it unless we have a shot at releasing a goodly
- * number of pages. Otherwise, the time taken isn't worth it.
+ * number of pages. Otherwise, the time taken isn't worth it, mainly because
+ * an AccessExclusive lock must be replayed on any hot standby, where it can
+ * be particularly disruptive.
*
* Also don't attempt it if wraparound failsafe is in effect. It's hard to
* predict how long lazy_truncate_heap will take. Don't take any chances.
diff --git a/src/test/isolation/expected/vacuum-reltuples.out b/src/test/isolation/expected/vacuum-reltuples.out
index cdbe7f3a6..ce55376e7 100644
--- a/src/test/isolation/expected/vacuum-reltuples.out
+++ b/src/test/isolation/expected/vacuum-reltuples.out
@@ -45,7 +45,7 @@ step stats:
relpages|reltuples
--------+---------
- 1| 20
+ 1| 21
(1 row)
diff --git a/src/test/isolation/specs/vacuum-reltuples.spec b/src/test/isolation/specs/vacuum-reltuples.spec
index ae2f79b8f..a2a461f2f 100644
--- a/src/test/isolation/specs/vacuum-reltuples.spec
+++ b/src/test/isolation/specs/vacuum-reltuples.spec
@@ -2,9 +2,10 @@
# to page pins. We absolutely need to avoid setting reltuples=0 in
# such cases, since that interferes badly with planning.
#
-# Expected result in second permutation is 20 tuples rather than 21 as
-# for the others, because vacuum should leave the previous result
-# (from before the insert) in place.
+# Expected result for all three permutation is 21 tuples, including
+# the second permutation. VACUUM is able to count the concurrently
+# inserted tuple in its final reltuples, even when a cleanup lock
+# cannot be acquired on the affected heap page.
setup {
create table smalltbl
--
2.30.2
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-11-22 19:29 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Andres Freund @ 2021-11-22 19:29 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Masahiko Sawada <[email protected]>
Hi,
On 2021-11-21 18:13:51 -0800, Peter Geoghegan wrote:
> I have heard many stories about anti-wraparound/aggressive VACUUMs
> where the cure (which suddenly made autovacuum workers
> non-cancellable) was worse than the disease (not actually much danger
> of wraparound failure). For example:
>
> https://www.joyent.com/blog/manta-postmortem-7-27-2015
>
> Yes, this problem report is from 2015, which is before we even had the
> freeze map stuff. I still think that the point about aggressive
> VACUUMs blocking DDL (leading to chaos) remains valid.
As I noted below, I think this is a bit of a separate issue than what your
changes address in this patch.
> There is another interesting area of future optimization within
> VACUUM, that also seems relevant to this patch: the general idea of
> *avoiding* pruning during VACUUM, when it just doesn't make sense to
> do so -- better to avoid dirtying the page for now. Needlessly pruning
> inside lazy_scan_prune is hardly rare -- standard pgbench (maybe only
> with heap fill factor reduced to 95) will have autovacuums that
> *constantly* do it (granted, it may not matter so much there because
> VACUUM is unlikely to re-dirty the page anyway).
Hm. I'm a bit doubtful that there's all that many cases where it's worth not
pruning during vacuum. However, it seems much more common for opportunistic
pruning during non-write accesses.
Perhaps checking whether we'd log an FPW would be a better criteria for
deciding whether to prune or not compared to whether we're dirtying the page?
IME the WAL volume impact of FPWs is a considerably bigger deal than
unnecessarily dirtying a page that has previously been dirtied in the same
checkpoint "cycle".
> This patch seems relevant to that area because it recognizes that pruning
> during VACUUM is not necessarily special -- a new function called
> lazy_scan_noprune may be used instead of lazy_scan_prune (though only when a
> cleanup lock cannot be acquired). These pages are nevertheless considered
> fully processed by VACUUM (this is perhaps 99% true, so it seems reasonable
> to round up to 100% true).
IDK, the potential of not having usable space on an overfly fragmented page
doesn't seem that low. We can't just mark such pages as all-visible because
then we'll potentially never reclaim that space.
> Since any VACUUM (not just an aggressive VACUUM) can sometimes advance
> relfrozenxid, we now make non-aggressive VACUUMs work just a little
> harder in order to make that desirable outcome more likely in practice.
> Aggressive VACUUMs have long checked contended pages with only a shared
> lock, to avoid needlessly waiting on a cleanup lock (in the common case
> where the contended page has no tuples that need to be frozen anyway).
> We still don't make non-aggressive VACUUMs wait for a cleanup lock, of
> course -- if we did that they'd no longer be non-aggressive.
IMO the big difference between aggressive / non-aggressive isn't whether we
wait for a cleanup lock, but that we don't skip all-visible pages...
> But we now make the non-aggressive case notice that a failure to acquire a
> cleanup lock on one particular heap page does not in itself make it unsafe
> to advance relfrozenxid for the whole relation (which is what we usually see
> in the aggressive case already).
>
> This new relfrozenxid optimization might not be all that valuable on its
> own, but it may still facilitate future work that makes non-aggressive
> VACUUMs more conscious of the benefit of advancing relfrozenxid sooner
> rather than later. In general it would be useful for non-aggressive
> VACUUMs to be "more aggressive" opportunistically (e.g., by waiting for
> a cleanup lock once or twice if needed).
What do you mean by "waiting once or twice"? A single wait may simply never
end on a busy page that's constantly pinned by a lot of backends...
> It would also be generally useful if aggressive VACUUMs were "less
> aggressive" opportunistically (e.g. by being responsive to query
> cancellations when the risk of wraparound failure is still very low).
Being canceleable is already a different concept than anti-wraparound
vacuums. We start aggressive autovacuums at vacuum_freeze_table_age, but
anti-wrap only at autovacuum_freeze_max_age. The problem is that the
autovacuum scheduling is way too naive for that to be a significant benefit -
nothing tries to schedule autovacuums so that they have a chance to complete
before anti-wrap autovacuums kick in. All that vacuum_freeze_table_age does is
to promote an otherwise-scheduled (auto-)vacuum to an aggressive vacuum.
This is one of the most embarassing issues around the whole anti-wrap
topic. We kind of define it as an emergency that there's an anti-wraparound
vacuum. But we have *absolutely no mechanism* to prevent them from occurring.
> We now also collect LP_DEAD items in the dead_tuples array in the case
> where we cannot immediately get a cleanup lock on the buffer. We cannot
> prune without a cleanup lock, but opportunistic pruning may well have
> left some LP_DEAD items behind in the past -- no reason to miss those.
This has become *much* more important with the changes around deciding when to
index vacuum. It's not just that opportunistic pruning could have left LP_DEAD
items, it's that a previous vacuum is quite likely to have left them there,
because the previous vacuum decided not to perform index cleanup.
> Only VACUUM can mark these LP_DEAD items LP_UNUSED (no opportunistic
> technique is independently capable of cleaning up line pointer bloat),
One thing we could do around this, btw, would be to aggressively replace
LP_REDIRECT items with their target item. We can't do that in all situations
(somebody might be following a ctid chain), but I think we have all the
information needed to do so. Probably would require a new HTSV RECENTLY_LIVE
state or something like that.
I think that'd be quite a win - we right now often "migrate" to other pages
for modifications not because we're out of space on a page, but because we run
out of itemids (for debatable reasons MaxHeapTuplesPerPage constraints the
number of line pointers, not just the number of actual tuples). Effectively
doubling the number of available line item in common cases in a number of
realistic / common scenarios would be quite the win.
> Note that we no longer report on "pin skipped pages" in VACUUM VERBOSE,
> since there is no barely any real practical sense in which we actually
> miss doing useful work for these pages. Besides, this information
> always seemed to have little practical value, even to Postgres hackers.
-0.5. I think it provides some value, and I don't see why the removal of the
information should be tied to this change. It's hard to diagnose why some dead
tuples aren't cleaned up - a common cause for that on smaller tables is that
nearly all pages are pinned nearly all the time.
I wonder if we could have a more restrained version of heap_page_prune() that
doesn't require a cleanup lock? Obviously we couldn't defragment the page, but
it's not immediately obvious that we need it if we constrain ourselves to only
modify tuple versions that cannot be visible to anybody.
Random note: I really dislike that we talk about cleanup locks in some parts
of the code, and super-exclusive locks in others :(.
> + /*
> + * Aggressive VACUUM (which is the same thing as anti-wraparound
> + * autovacuum for most practical purposes) exists so that we'll reliably
> + * advance relfrozenxid and relminmxid sooner or later. But we can often
> + * opportunistically advance them even in a non-aggressive VACUUM.
> + * Consider if that's possible now.
I don't agree with the "most practical purposes" bit. There's a huge
difference because manual VACUUMs end up aggressive but not anti-wrap once
older than vacuum_freeze_table_age.
> + * NB: We must use orig_rel_pages, not vacrel->rel_pages, since we want
> + * the rel_pages used by lazy_scan_prune, from before a possible relation
> + * truncation took place. (vacrel->rel_pages is now new_rel_pages.)
> + */
I think it should be doable to add an isolation test for this path. There have
been quite a few bugs around the wider topic...
> + if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
> + !vacrel->freeze_cutoffs_valid)
> + {
> + /* Cannot advance relfrozenxid/relminmxid -- just update pg_class */
> + Assert(!aggressive);
> + vac_update_relstats(rel, new_rel_pages, new_live_tuples,
> + new_rel_allvisible, vacrel->nindexes > 0,
> + InvalidTransactionId, InvalidMultiXactId, false);
> + }
> + else
> + {
> + /* Can safely advance relfrozen and relminmxid, too */
> + Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
> + orig_rel_pages);
> + vac_update_relstats(rel, new_rel_pages, new_live_tuples,
> + new_rel_allvisible, vacrel->nindexes > 0,
> + FreezeLimit, MultiXactCutoff, false);
> + }
I wonder if this whole logic wouldn't become easier and less fragile if we
just went for maintaining the "actually observed" horizon while scanning the
relation. If we skip a page via VM set the horizon to invalid. Otherwise we
can keep track of the accurate horizon and use that. No need to count pages
and stuff.
> @@ -1050,18 +1046,14 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
> bool all_visible_according_to_vm = false;
> LVPagePruneState prunestate;
>
> - /*
> - * Consider need to skip blocks. See note above about forcing
> - * scanning of last page.
> - */
> -#define FORCE_CHECK_PAGE() \
> - (blkno == nblocks - 1 && should_attempt_truncation(vacrel))
> -
> pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
>
> update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
> blkno, InvalidOffsetNumber);
>
> + /*
> + * Consider need to skip blocks
> + */
> if (blkno == next_unskippable_block)
> {
> /* Time to advance next_unskippable_block */
> @@ -1110,13 +1102,19 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
> else
> {
> /*
> - * The current block is potentially skippable; if we've seen a
> - * long enough run of skippable blocks to justify skipping it, and
> - * we're not forced to check it, then go ahead and skip.
> - * Otherwise, the page must be at least all-visible if not
> - * all-frozen, so we can set all_visible_according_to_vm = true.
> + * The current block can be skipped if we've seen a long enough
> + * run of skippable blocks to justify skipping it.
> + *
> + * There is an exception: we will scan the table's last page to
> + * determine whether it has tuples or not, even if it would
> + * otherwise be skipped (unless it's clearly not worth trying to
> + * truncate the table). This avoids having lazy_truncate_heap()
> + * take access-exclusive lock on the table to attempt a truncation
> + * that just fails immediately because there are tuples in the
> + * last page.
> */
> - if (skipping_blocks && !FORCE_CHECK_PAGE())
> + if (skipping_blocks &&
> + !(blkno == nblocks - 1 && should_attempt_truncation(vacrel)))
> {
> /*
> * Tricky, tricky. If this is in aggressive vacuum, the page
I find the FORCE_CHECK_PAGE macro decidedly unhelpful. But I don't like
mixing such changes within a larger change doing many other things.
> @@ -1204,156 +1214,52 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
>
> buf = ReadBufferExtended(vacrel->rel, MAIN_FORKNUM, blkno,
> RBM_NORMAL, vacrel->bstrategy);
> + page = BufferGetPage(buf);
> + vacrel->scanned_pages++;
I don't particularly like doing BufferGetPage() before holding a lock on the
page. Perhaps I'm too influenced by rust etc, but ISTM that at some point it'd
be good to have a crosscheck that BufferGetPage() is only allowed when holding
a page level lock.
> /*
> - * We need buffer cleanup lock so that we can prune HOT chains and
> - * defragment the page.
> + * We need a buffer cleanup lock to prune HOT chains and defragment
> + * the page in lazy_scan_prune. But when it's not possible to acquire
> + * a cleanup lock right away, we may be able to settle for reduced
> + * processing in lazy_scan_noprune.
> */
s/in lazy_scan_noprune/via lazy_scan_noprune/?
> if (!ConditionalLockBufferForCleanup(buf))
> {
> bool hastup;
>
> - /*
> - * If we're not performing an aggressive scan to guard against XID
> - * wraparound, and we don't want to forcibly check the page, then
> - * it's OK to skip vacuuming pages we get a lock conflict on. They
> - * will be dealt with in some future vacuum.
> - */
> - if (!aggressive && !FORCE_CHECK_PAGE())
> + LockBuffer(buf, BUFFER_LOCK_SHARE);
> +
> + /* Check for new or empty pages before lazy_scan_noprune call */
> + if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, true,
> + vmbuffer))
> {
> - ReleaseBuffer(buf);
> - vacrel->pinskipped_pages++;
> + /* Lock and pin released for us */
> + continue;
> + }
Why isn't this done in lazy_scan_noprune()?
> + if (lazy_scan_noprune(vacrel, buf, blkno, page, &hastup))
> + {
> + /* No need to wait for cleanup lock for this page */
> + UnlockReleaseBuffer(buf);
> + if (hastup)
> + vacrel->nonempty_pages = blkno + 1;
> continue;
> }
Do we really need all of buf, blkno, page for both of these functions? Quite
possible that yes, if so, could we add an assertion that
BufferGetBockNumber(buf) == blkno?
> + /* Check for new or empty pages before lazy_scan_prune call */
> + if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, false, vmbuffer))
> {
Maybe worth a note mentioning that we need to redo this even in the aggressive
case, because we didn't continually hold a lock on the page?
> +/*
> + * Empty pages are not really a special case -- they're just heap pages that
> + * have no allocated tuples (including even LP_UNUSED items). You might
> + * wonder why we need to handle them here all the same. It's only necessary
> + * because of a rare corner-case involving a hard crash during heap relation
> + * extension. If we ever make relation-extension crash safe, then it should
> + * no longer be necessary to deal with empty pages here (or new pages, for
> + * that matter).
I don't think it's actually that rare - the window for this is huge. You just
need to crash / immediate shutdown at any time between the relation having
been extended and the new page contents being written out (checkpoint or
buffer replacement / ring writeout). That's often many minutes.
I don't really see that as a realistic thing to ever reliably avoid, FWIW. I
think the overhead would be prohibitive. We'd need to do synchronous WAL
logging while holding the extension lock I think. Um, not fun.
> + * Caller can either hold a buffer cleanup lock on the buffer, or a simple
> + * shared lock.
> + */
Kinda sounds like it'd be incorrect to call this with an exclusive lock, which
made me wonder why that could be true. Perhaps just say that it needs to be
called with at least a shared lock?
> +static bool
> +lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf, BlockNumber blkno,
> + Page page, bool sharelock, Buffer vmbuffer)
It'd be good to document the return value - for me it's not a case where it's
so obvious that it's not worth it.
> +/*
> + * lazy_scan_noprune() -- lazy_scan_prune() variant without pruning
> + *
> + * Caller need only hold a pin and share lock on the buffer, unlike
> + * lazy_scan_prune, which requires a full cleanup lock.
I'd add somethign like "returns whether a cleanup lock is required". Having to
read multiple paragraphs to understand the basic meaning of the return value
isn't great.
> + if (ItemIdIsRedirected(itemid))
> + {
> + *hastup = true; /* page won't be truncatable */
> + continue;
> + }
It's not really new, but this comment is now a bit confusing, because it can
be understood to be about PageTruncateLinePointerArray().
> + case HEAPTUPLE_DEAD:
> + case HEAPTUPLE_RECENTLY_DEAD:
> +
> + /*
> + * We count DEAD and RECENTLY_DEAD tuples in new_dead_tuples.
> + *
> + * lazy_scan_prune only does this for RECENTLY_DEAD tuples,
> + * and never has to deal with DEAD tuples directly (they
> + * reliably become LP_DEAD items through pruning). Our
> + * approach to DEAD tuples is a bit arbitrary, but it seems
> + * better than totally ignoring them.
> + */
> + new_dead_tuples++;
> + break;
Why does it make sense to track DEAD tuples this way? Isn't that going to lead
to counting them over-and-over again? I think it's quite misleading to include
them in "dead bot not yet removable".
> + /*
> + * Now save details of the LP_DEAD items from the page in the dead_tuples
> + * array iff VACUUM uses two-pass strategy case
> + */
Do we really need to have separate code for this in lazy_scan_prune() and
lazy_scan_noprune()?
> + }
> + else
> + {
> + /*
> + * We opt to skip FSM processing for the page on the grounds that it
> + * is probably being modified by concurrent DML operations. Seems
> + * best to assume that the space is best left behind for future
> + * updates of existing tuples. This matches what opportunistic
> + * pruning does.
Why can we assume that there concurrent DML rather than concurrent read-only
operations? IME it's much more common for read-only operations to block
cleanup locks than read-write ones (partially because the frequency makes it
easier, partially because cursors allow long-held pins, partially because the
EXCLUSIVE lock of a r/w operation wouldn't let us get here)
I think this is a change mostly in the right direction. But as formulated this
commit does *WAY* too much at once.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-11-23 01:07 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2021-11-23 01:07 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Masahiko Sawada <[email protected]>
On Mon, Nov 22, 2021 at 11:29 AM Andres Freund <[email protected]> wrote:
> Hm. I'm a bit doubtful that there's all that many cases where it's worth not
> pruning during vacuum. However, it seems much more common for opportunistic
> pruning during non-write accesses.
Fair enough. I just wanted to suggest an exploratory conversation
about pruning (among several other things). I'm mostly saying: hey,
pruning during VACUUM isn't actually that special, at least not with
this refactoring patch in place. So maybe it makes sense to go
further, in light of that general observation about pruning in VACUUM.
Maybe it wasn't useful to even mention this aspect now. I would rather
focus on freezing optimizations for now -- that's much more promising.
> Perhaps checking whether we'd log an FPW would be a better criteria for
> deciding whether to prune or not compared to whether we're dirtying the page?
> IME the WAL volume impact of FPWs is a considerably bigger deal than
> unnecessarily dirtying a page that has previously been dirtied in the same
> checkpoint "cycle".
Agreed. (I tend to say the former when I really mean the latter, which
I should try to avoid.)
> IDK, the potential of not having usable space on an overfly fragmented page
> doesn't seem that low. We can't just mark such pages as all-visible because
> then we'll potentially never reclaim that space.
Don't get me started on this - because I'll never stop.
It makes zero sense that we don't think about free space holistically,
using the whole context of what changed in the recent past. As I think
you know already, a higher level concept (like open and closed pages)
seems like the right direction to me -- because it isn't sensible to
treat X bytes of free space in one heap page as essentially
interchangeable with any other space on any other heap page. That
misses an enormous amount of things that matter. The all-visible
status of a page is just one such thing.
> IMO the big difference between aggressive / non-aggressive isn't whether we
> wait for a cleanup lock, but that we don't skip all-visible pages...
I know what you mean by that, of course. But FWIW that definition
seems too focused on what actually happens today, rather than what is
essential given the invariants we have for VACUUM. And so I personally
prefer to define it as "a VACUUM that *reliably* advances
relfrozenxid". This looser definition will probably "age" well (ahem).
> > This new relfrozenxid optimization might not be all that valuable on its
> > own, but it may still facilitate future work that makes non-aggressive
> > VACUUMs more conscious of the benefit of advancing relfrozenxid sooner
> > rather than later. In general it would be useful for non-aggressive
> > VACUUMs to be "more aggressive" opportunistically (e.g., by waiting for
> > a cleanup lock once or twice if needed).
>
> What do you mean by "waiting once or twice"? A single wait may simply never
> end on a busy page that's constantly pinned by a lot of backends...
I was speculating about future work again. I think that you've taken
my words too literally. This is just a draft commit message, just a
way of framing what I'm really trying to do.
Sure, it wouldn't be okay to wait *indefinitely* for any one pin in a
non-aggressive VACUUM -- so "at least waiting for one or two pins
during non-aggressive VACUUM" might not have been the best way of
expressing the idea that I wanted to express. The important point is
that _we can make a choice_ about stuff like this dynamically, based
on the observed characteristics of the table, and some general ideas
about the costs and benefits (of waiting or not waiting, or of how
long we want to wait in total, whatever might be important). This
probably just means adding some heuristics that are pretty sensitive
to any reason to not do more work in a non-aggressive VACUUM, without
*completely* balking at doing even a tiny bit more work.
For example, we can definitely afford to wait a few more milliseconds
to get a cleanup lock just once, especially if we're already pretty
sure that that's all the extra work that it would take to ultimately
be able to advance relfrozenxid in the ongoing (non-aggressive) VACUUM
-- it's easy to make that case. Once you agree that it makes sense
under these favorable circumstances, you've already made
"aggressiveness" a continuous thing conceptually, at a high level.
The current binary definition of "aggressive" is needlessly
restrictive -- that much seems clear to me. I'm much less sure of what
specific alternative should replace it.
I've already prototyped advancing relfrozenxid using a dynamically
determined value, so that our final relfrozenxid is just about the
most recent safe value (not the original FreezeLimit). That's been
interesting. Consider this log output from an autovacuum with the
prototype patch (also uses my new instrumentation), based on standard
pgbench (just tuned heap fill factor a bit):
LOG: automatic vacuum of table "regression.public.pgbench_accounts":
index scans: 0
pages: 0 removed, 909091 remain, 33559 skipped using visibility map
(3.69% of total)
tuples: 297113 removed, 50090880 remain, 90880 are dead but not yet removable
removal cutoff: oldest xmin was 29296744, which is now 203341 xact IDs behind
index scan not needed: 0 pages from table (0.00% of total) had 0 dead
item identifiers removed
I/O timings: read: 55.574 ms, write: 0.000 ms
avg read rate: 17.805 MB/s, avg write rate: 4.389 MB/s
buffer usage: 1728273 hits, 23150 misses, 5706 dirtied
WAL usage: 594211 records, 0 full page images, 35065032 bytes
system usage: CPU: user: 6.85 s, system: 0.08 s, elapsed: 10.15 s
All of the autovacuums against the accounts table look similar to this
one -- you don't see anything about relfrozenxid being advanced
(because it isn't). Whereas for the smaller pgbench tables, every
single VACUUM successfully advances relfrozenxid to a fairly recent
XID (without there ever being an aggressive VACUUM) -- just because
VACUUM needs to visit every page for the smaller tables. While the
accounts table doesn't generally need to have 100% of all pages
touched by VACUUM -- it's more like 95% there. Does that really make
sense, though?
I'm pretty sure that less aggressive VACUUMing (e.g. higher
scale_factor setting) would lead to more aggressive setting of
relfrozenxid here. I'm always suspicious when I see insignificant
differences that lead to significant behavioral differences. Am I
worried over nothing here? Perhaps -- we don't really need to advance
relfrozenxid early with this table/workload anyway. But I'm not so
sure.
Again, my point is that there is a good chance that redefining
aggressiveness in some way will be helpful. A more creative, flexible
definition might be just what we need. The details are very much up in
the air, though.
> > It would also be generally useful if aggressive VACUUMs were "less
> > aggressive" opportunistically (e.g. by being responsive to query
> > cancellations when the risk of wraparound failure is still very low).
>
> Being canceleable is already a different concept than anti-wraparound
> vacuums. We start aggressive autovacuums at vacuum_freeze_table_age, but
> anti-wrap only at autovacuum_freeze_max_age.
You know what I meant. Also, did *you* mean "being canceleable is
already a different concept to *aggressive* vacuums"? :-)
> The problem is that the
> autovacuum scheduling is way too naive for that to be a significant benefit -
> nothing tries to schedule autovacuums so that they have a chance to complete
> before anti-wrap autovacuums kick in. All that vacuum_freeze_table_age does is
> to promote an otherwise-scheduled (auto-)vacuum to an aggressive vacuum.
Not sure what you mean about scheduling, since vacuum_freeze_table_age
is only in place to make overnight (off hours low activity scripted
VACUUMs) freeze tuples before any autovacuum worker gets the chance
(since the latter may run at a much less convenient time). Sure,
vacuum_freeze_table_age might also force a regular autovacuum worker
to do an aggressive VACUUM -- but I think it's mostly intended for a
manual overnight VACUUM. Not usually very helpful, but also not
harmful.
Oh, wait. I think that you're talking about how autovacuum workers in
particular tend to be affected by this. We launch an av worker that
wants to clean up bloat, but it ends up being aggressive (and maybe
taking way longer), perhaps quite randomly, only due to
vacuum_freeze_table_age (not due to autovacuum_freeze_max_age). Is
that it?
> This is one of the most embarassing issues around the whole anti-wrap
> topic. We kind of define it as an emergency that there's an anti-wraparound
> vacuum. But we have *absolutely no mechanism* to prevent them from occurring.
What do you mean? Only an autovacuum worker can do an anti-wraparound
VACUUM (which is not quite the same thing as an aggressive VACUUM).
I agree that anti-wraparound autovacuum is way too unfriendly, though.
> > We now also collect LP_DEAD items in the dead_tuples array in the case
> > where we cannot immediately get a cleanup lock on the buffer. We cannot
> > prune without a cleanup lock, but opportunistic pruning may well have
> > left some LP_DEAD items behind in the past -- no reason to miss those.
>
> This has become *much* more important with the changes around deciding when to
> index vacuum. It's not just that opportunistic pruning could have left LP_DEAD
> items, it's that a previous vacuum is quite likely to have left them there,
> because the previous vacuum decided not to perform index cleanup.
I haven't seen any evidence of that myself (with the optimization
added to Postgres 14 by commit 5100010ee4). I still don't understand
why you doubted that work so much. I'm not saying that you're wrong
to; I'm saying that I don't think that I understand your perspective
on it.
What I have seen in my own tests (particularly with BenchmarkSQL) is
that most individual tables either never apply the optimization even
once (because the table reliably has heap pages with many more LP_DEAD
items than the 2%-of-relpages threshold), or will never need to
(because there are precisely zero LP_DEAD items anyway). Remaining
tables that *might* use the optimization tend to not go very long
without actually getting a round of index vacuuming. It's just too
easy for updates (and even aborted xact inserts) to introduce new
LP_DEAD items for us to go long without doing index vacuuming.
If you can be more concrete about a problem you've seen, then I might
be able to help. It's not like there are no options in this already. I
already thought about introducing a small degree of randomness into
the process of deciding to skip or to not skip (in the
consider_bypass_optimization path of lazy_vacuum() on Postgres 14).
The optimization is mostly valuable because it allows us to do more
useful work in VACUUM -- not because it allows us to do less useless
work in VACUUM. In particular, it allows to tune
autovacuum_vacuum_insert_scale_factor very aggressively with an
append-only table, without useless index vacuuming making it all but
impossible for autovacuum to get to the useful work.
> > Only VACUUM can mark these LP_DEAD items LP_UNUSED (no opportunistic
> > technique is independently capable of cleaning up line pointer bloat),
>
> One thing we could do around this, btw, would be to aggressively replace
> LP_REDIRECT items with their target item. We can't do that in all situations
> (somebody might be following a ctid chain), but I think we have all the
> information needed to do so. Probably would require a new HTSV RECENTLY_LIVE
> state or something like that.
Another idea is to truncate the line pointer during pruning (including
opportunistic pruning). Matthias van de Meent has a patch for that.
I am not aware of a specific workload where the patch helps, but that
doesn't mean that there isn't one, or that it doesn't matter. It's
subtle enough that I might have just missed something. I *expect* the
true damage over time to be very hard to model or understand -- I
imagine the potential for weird feedback loops is there.
> I think that'd be quite a win - we right now often "migrate" to other pages
> for modifications not because we're out of space on a page, but because we run
> out of itemids (for debatable reasons MaxHeapTuplesPerPage constraints the
> number of line pointers, not just the number of actual tuples). Effectively
> doubling the number of available line item in common cases in a number of
> realistic / common scenarios would be quite the win.
I believe Masahiko is working on this in the current cycle. It would
be easier if we had a better sense of how increasing
MaxHeapTuplesPerPage will affect tidbitmap.c. But the idea of
increasing that seems sound to me.
> > Note that we no longer report on "pin skipped pages" in VACUUM VERBOSE,
> > since there is no barely any real practical sense in which we actually
> > miss doing useful work for these pages. Besides, this information
> > always seemed to have little practical value, even to Postgres hackers.
>
> -0.5. I think it provides some value, and I don't see why the removal of the
> information should be tied to this change. It's hard to diagnose why some dead
> tuples aren't cleaned up - a common cause for that on smaller tables is that
> nearly all pages are pinned nearly all the time.
Is that still true, though? If it turns out that we need to leave it
in, then I can do that. But I'd prefer to wait until we have more
information before making a final decision. Remember, the high level
idea of this whole patch is that we do as much work as possible for
any scanned_pages, which now includes pages that we never successfully
acquired a cleanup lock on. And so we're justified in assuming that
they're exactly equivalent to pages that we did get a cleanup on --
that's now the working assumption. I know that that's not literally
true, but that doesn't mean it's not a useful fiction -- it should be
very close to the truth.
Also, I would like to put more information (much more useful
information) in the same log output. Perhaps that will be less
controversial if I take something useless away first.
> I wonder if we could have a more restrained version of heap_page_prune() that
> doesn't require a cleanup lock? Obviously we couldn't defragment the page, but
> it's not immediately obvious that we need it if we constrain ourselves to only
> modify tuple versions that cannot be visible to anybody.
>
> Random note: I really dislike that we talk about cleanup locks in some parts
> of the code, and super-exclusive locks in others :(.
Somebody should normalize that.
> > + /*
> > + * Aggressive VACUUM (which is the same thing as anti-wraparound
> > + * autovacuum for most practical purposes) exists so that we'll reliably
> > + * advance relfrozenxid and relminmxid sooner or later. But we can often
> > + * opportunistically advance them even in a non-aggressive VACUUM.
> > + * Consider if that's possible now.
>
> I don't agree with the "most practical purposes" bit. There's a huge
> difference because manual VACUUMs end up aggressive but not anti-wrap once
> older than vacuum_freeze_table_age.
Okay.
> > + * NB: We must use orig_rel_pages, not vacrel->rel_pages, since we want
> > + * the rel_pages used by lazy_scan_prune, from before a possible relation
> > + * truncation took place. (vacrel->rel_pages is now new_rel_pages.)
> > + */
>
> I think it should be doable to add an isolation test for this path. There have
> been quite a few bugs around the wider topic...
I would argue that we already have one -- vacuum-reltuples.spec. I had
to update its expected output in the patch. I would argue that the
behavioral change (count tuples on a pinned-by-cursor heap page) that
necessitated updating the expected output for the test is an
improvement overall.
> > + {
> > + /* Can safely advance relfrozen and relminmxid, too */
> > + Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
> > + orig_rel_pages);
> > + vac_update_relstats(rel, new_rel_pages, new_live_tuples,
> > + new_rel_allvisible, vacrel->nindexes > 0,
> > + FreezeLimit, MultiXactCutoff, false);
> > + }
>
> I wonder if this whole logic wouldn't become easier and less fragile if we
> just went for maintaining the "actually observed" horizon while scanning the
> relation. If we skip a page via VM set the horizon to invalid. Otherwise we
> can keep track of the accurate horizon and use that. No need to count pages
> and stuff.
There is no question that that makes sense as an optimization -- my
prototype convinced me of that already. But I don't think that it can
simplify anything (not even the call to vac_update_relstats itself, to
actually update relfrozenxid at the end). Fundamentally, this will
only work if we decide to only skip all-frozen pages, which (by
definition) only happens within aggressive VACUUMs. Isn't it that
simple?
You recently said (on the heap-pruning-14-bug thread) that you don't
think it would be practical to always set a page all-frozen when we
see that we're going to set it all-visible -- apparently you feel that
we could never opportunistically freeze early such that all-visible
but not all-frozen pages practically cease to exist. I'm still not
sure why you believe that (though you may be right, or I might have
misunderstood, since it's complicated). It would certainly benefit
this dynamic relfrozenxid business if it was possible, though. If we
could somehow make that work, then almost every VACUUM would be able
to advance relfrozenxid, independently of aggressive-ness -- because
we wouldn't have any all-visible-but-not-all-frozen pages to skip
(that important detail wouldn't be left to chance).
> > - if (skipping_blocks && !FORCE_CHECK_PAGE())
> > + if (skipping_blocks &&
> > + !(blkno == nblocks - 1 && should_attempt_truncation(vacrel)))
> > {
> > /*
> > * Tricky, tricky. If this is in aggressive vacuum, the page
>
> I find the FORCE_CHECK_PAGE macro decidedly unhelpful. But I don't like
> mixing such changes within a larger change doing many other things.
I got rid of FORCE_CHECK_PAGE() itself in this patch (not a later
patch) because the patch also removes the only other
FORCE_CHECK_PAGE() call -- and the latter change is very much in scope
for the big patch (can't be broken down into smaller changes, I
think). And so this felt natural to me. But if you prefer, I can break
it out into a separate commit.
> > @@ -1204,156 +1214,52 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
> >
> > buf = ReadBufferExtended(vacrel->rel, MAIN_FORKNUM, blkno,
> > RBM_NORMAL, vacrel->bstrategy);
> > + page = BufferGetPage(buf);
> > + vacrel->scanned_pages++;
>
> I don't particularly like doing BufferGetPage() before holding a lock on the
> page. Perhaps I'm too influenced by rust etc, but ISTM that at some point it'd
> be good to have a crosscheck that BufferGetPage() is only allowed when holding
> a page level lock.
I have occasionally wondered if the whole idea of reading heap pages
with only a pin (and having cleanup locks in VACUUM) is really worth
it -- alternative designs seem possible. Obviously that's a BIG
discussion, and not one to have right now. But it seems kind of
relevant.
Since it is often legit to read a heap page without a buffer lock
(only a pin), I can't see why BufferGetPage() without a buffer lock
shouldn't also be okay -- if anything it seems safer. I think that I
would agree with you if it wasn't for that inconsistency (which is
rather a big "if", to be sure -- even for me).
> > + /* Check for new or empty pages before lazy_scan_noprune call */
> > + if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, true,
> > + vmbuffer))
> > {
> > - ReleaseBuffer(buf);
> > - vacrel->pinskipped_pages++;
> > + /* Lock and pin released for us */
> > + continue;
> > + }
>
> Why isn't this done in lazy_scan_noprune()?
No reason, really -- could be done that way (we'd then also give
lazy_scan_prune the same treatment). I thought that it made a certain
amount of sense to keep some of this in the main loop, but I can
change it if you want.
> > + if (lazy_scan_noprune(vacrel, buf, blkno, page, &hastup))
> > + {
> > + /* No need to wait for cleanup lock for this page */
> > + UnlockReleaseBuffer(buf);
> > + if (hastup)
> > + vacrel->nonempty_pages = blkno + 1;
> > continue;
> > }
>
> Do we really need all of buf, blkno, page for both of these functions? Quite
> possible that yes, if so, could we add an assertion that
> BufferGetBockNumber(buf) == blkno?
This just matches the existing lazy_scan_prune function (which doesn't
mean all that much, since it was only added in Postgres 14). Will add
the assertion to both.
> > + /* Check for new or empty pages before lazy_scan_prune call */
> > + if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, false, vmbuffer))
> > {
>
> Maybe worth a note mentioning that we need to redo this even in the aggressive
> case, because we didn't continually hold a lock on the page?
Isn't that obvious? Either way it isn't the kind of thing that I'd try
to optimize away. It's such a narrow issue.
> > +/*
> > + * Empty pages are not really a special case -- they're just heap pages that
> > + * have no allocated tuples (including even LP_UNUSED items). You might
> > + * wonder why we need to handle them here all the same. It's only necessary
> > + * because of a rare corner-case involving a hard crash during heap relation
> > + * extension. If we ever make relation-extension crash safe, then it should
> > + * no longer be necessary to deal with empty pages here (or new pages, for
> > + * that matter).
>
> I don't think it's actually that rare - the window for this is huge.
I can just remove the comment, though it still makes sense to me.
> I don't really see that as a realistic thing to ever reliably avoid, FWIW. I
> think the overhead would be prohibitive. We'd need to do synchronous WAL
> logging while holding the extension lock I think. Um, not fun.
My long term goal for the FSM (the lease based design I talked about
earlier this year) includes soft ownership of free space from
preallocated pages by individual xacts -- the smgr layer itself
becomes transactional and crash safe (at least to a limited degree).
This includes bulk extension of relations, to make up for the new
overhead implied by crash safe rel extension. I don't think that we
should require VACUUM (or anything else) to be cool with random
uninitialized pages -- to me that just seems backwards.
We can't do true bulk extension right now (just an inferior version
that doesn't give specific pages to specific backends) because the
risk of losing a bunch of empty pages for way too long is not
acceptable. But that doesn't seem fundamental to me -- that's one of
the things we'd be fixing at the same time (through what I call soft
ownership semantics). I think we'd come out ahead on performance, and
*also* have a more robust approach to relation extension.
> > + * Caller can either hold a buffer cleanup lock on the buffer, or a simple
> > + * shared lock.
> > + */
>
> Kinda sounds like it'd be incorrect to call this with an exclusive lock, which
> made me wonder why that could be true. Perhaps just say that it needs to be
> called with at least a shared lock?
Okay.
> > +static bool
> > +lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf, BlockNumber blkno,
> > + Page page, bool sharelock, Buffer vmbuffer)
>
> It'd be good to document the return value - for me it's not a case where it's
> so obvious that it's not worth it.
Okay.
> > +/*
> > + * lazy_scan_noprune() -- lazy_scan_prune() variant without pruning
> > + *
> > + * Caller need only hold a pin and share lock on the buffer, unlike
> > + * lazy_scan_prune, which requires a full cleanup lock.
>
> I'd add somethign like "returns whether a cleanup lock is required". Having to
> read multiple paragraphs to understand the basic meaning of the return value
> isn't great.
Will fix.
> > + if (ItemIdIsRedirected(itemid))
> > + {
> > + *hastup = true; /* page won't be truncatable */
> > + continue;
> > + }
>
> It's not really new, but this comment is now a bit confusing, because it can
> be understood to be about PageTruncateLinePointerArray().
I didn't think of that. Will address it in the next version.
> Why does it make sense to track DEAD tuples this way? Isn't that going to lead
> to counting them over-and-over again? I think it's quite misleading to include
> them in "dead bot not yet removable".
Compared to what? Do we really want to invent a new kind of DEAD tuple
(e.g., to report on), just to handle this rare case?
I accept that this code is lying about the tuples being RECENTLY_DEAD,
kind of. But isn't it still strictly closer to the truth, compared to
HEAD? Counting it as RECENTLY_DEAD is far closer to the truth than not
counting it at all.
Note that we don't remember LP_DEAD items here, either (not here, in
lazy_scan_noprune, and not in lazy_scan_prune on HEAD). Because we
pretty much interpret LP_DEAD items as "future LP_UNUSED items"
instead -- we make a soft assumption that we're going to go on to mark
the same items LP_UNUSED during a second pass over the heap. My point
is that there is no natural way to count "fully DEAD tuple that
autovacuum didn't deal with" -- and so I picked RECENTLY_DEAD.
> > + /*
> > + * Now save details of the LP_DEAD items from the page in the dead_tuples
> > + * array iff VACUUM uses two-pass strategy case
> > + */
>
> Do we really need to have separate code for this in lazy_scan_prune() and
> lazy_scan_noprune()?
There is hardly any repetition, though.
> > + }
> > + else
> > + {
> > + /*
> > + * We opt to skip FSM processing for the page on the grounds that it
> > + * is probably being modified by concurrent DML operations. Seems
> > + * best to assume that the space is best left behind for future
> > + * updates of existing tuples. This matches what opportunistic
> > + * pruning does.
>
> Why can we assume that there concurrent DML rather than concurrent read-only
> operations? IME it's much more common for read-only operations to block
> cleanup locks than read-write ones (partially because the frequency makes it
> easier, partially because cursors allow long-held pins, partially because the
> EXCLUSIVE lock of a r/w operation wouldn't let us get here)
I actually agree. It still probably isn't worth dealing with the FSM
here, though. It's just too much mechanism for too little benefit in a
very rare case. What do you think?
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-11-23 05:49 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Andres Freund @ 2021-11-23 05:49 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Masahiko Sawada <[email protected]>
Hi,
On 2021-11-22 17:07:46 -0800, Peter Geoghegan wrote:
> Sure, it wouldn't be okay to wait *indefinitely* for any one pin in a
> non-aggressive VACUUM -- so "at least waiting for one or two pins
> during non-aggressive VACUUM" might not have been the best way of
> expressing the idea that I wanted to express. The important point is
> that _we can make a choice_ about stuff like this dynamically, based
> on the observed characteristics of the table, and some general ideas
> about the costs and benefits (of waiting or not waiting, or of how
> long we want to wait in total, whatever might be important). This
> probably just means adding some heuristics that are pretty sensitive
> to any reason to not do more work in a non-aggressive VACUUM, without
> *completely* balking at doing even a tiny bit more work.
> For example, we can definitely afford to wait a few more milliseconds
> to get a cleanup lock just once
We currently have no infrastructure to wait for an lwlock or pincount for a
limited time. And at least for the former it'd not be easy to add. It may be
worth adding that at some point, but I'm doubtful this is sufficient reason
for nontrivial new infrastructure in very performance sensitive areas.
> All of the autovacuums against the accounts table look similar to this
> one -- you don't see anything about relfrozenxid being advanced
> (because it isn't). Whereas for the smaller pgbench tables, every
> single VACUUM successfully advances relfrozenxid to a fairly recent
> XID (without there ever being an aggressive VACUUM) -- just because
> VACUUM needs to visit every page for the smaller tables. While the
> accounts table doesn't generally need to have 100% of all pages
> touched by VACUUM -- it's more like 95% there. Does that really make
> sense, though?
Does what make really sense?
> I'm pretty sure that less aggressive VACUUMing (e.g. higher
> scale_factor setting) would lead to more aggressive setting of
> relfrozenxid here. I'm always suspicious when I see insignificant
> differences that lead to significant behavioral differences. Am I
> worried over nothing here? Perhaps -- we don't really need to advance
> relfrozenxid early with this table/workload anyway. But I'm not so
> sure.
I think pgbench_accounts is just a really poor showcase. Most importantly
there's no even slightly longer running transactions that hold down the xid
horizon. But in real workloads thats incredibly common IME. It's also quite
uncommon in real workloads to huge tables in which all records are
updated. It's more common to have value ranges that are nearly static, and a
more heavily changing range.
I think the most interesting cases where using the "measured" horizon will be
advantageous is anti-wrap vacuums. Those obviously have to happen for rarely
modified tables, including completely static ones, too. Using the "measured"
horizon will allow us to reduce the frequency of anti-wrap autovacuums on old
tables, because we'll be able to set a much more recent relfrozenxid.
This is becoming more common with the increased use of partitioning.
> > The problem is that the
> > autovacuum scheduling is way too naive for that to be a significant benefit -
> > nothing tries to schedule autovacuums so that they have a chance to complete
> > before anti-wrap autovacuums kick in. All that vacuum_freeze_table_age does is
> > to promote an otherwise-scheduled (auto-)vacuum to an aggressive vacuum.
>
> Not sure what you mean about scheduling, since vacuum_freeze_table_age
> is only in place to make overnight (off hours low activity scripted
> VACUUMs) freeze tuples before any autovacuum worker gets the chance
> (since the latter may run at a much less convenient time). Sure,
> vacuum_freeze_table_age might also force a regular autovacuum worker
> to do an aggressive VACUUM -- but I think it's mostly intended for a
> manual overnight VACUUM. Not usually very helpful, but also not
> harmful.
> Oh, wait. I think that you're talking about how autovacuum workers in
> particular tend to be affected by this. We launch an av worker that
> wants to clean up bloat, but it ends up being aggressive (and maybe
> taking way longer), perhaps quite randomly, only due to
> vacuum_freeze_table_age (not due to autovacuum_freeze_max_age). Is
> that it?
No, not quite. We treat anti-wraparound vacuums as an emergency (including
logging messages, not cancelling). But the only mechanism we have against
anti-wrap vacuums happening is vacuum_freeze_table_age. But as you say, that's
not really a "real" mechanism, because it requires an "independent" reason to
vacuum a table.
I've seen cases where anti-wraparound vacuums weren't a problem / never
happend for important tables for a long time, because there always was an
"independent" reason for autovacuum to start doing its thing before the table
got to be autovacuum_freeze_max_age old. But at some point the important
tables started to be big enough that autovacuum didn't schedule vacuums that
got promoted to aggressive via vacuum_freeze_table_age before the anti-wrap
vacuums. Then things started to burn, because of the unpaced anti-wrap vacuums
clogging up all IO, or maybe it was the vacuums not cancelling - I don't quite
remember the details.
Behaviour that lead to a "sudden" falling over, rather than getting gradually
worse are bad - they somehow tend to happen on Friday evenings :).
> > This is one of the most embarassing issues around the whole anti-wrap
> > topic. We kind of define it as an emergency that there's an anti-wraparound
> > vacuum. But we have *absolutely no mechanism* to prevent them from occurring.
>
> What do you mean? Only an autovacuum worker can do an anti-wraparound
> VACUUM (which is not quite the same thing as an aggressive VACUUM).
Just that autovacuum should have a mechanism to trigger aggressive vacuums
(i.e. ones that are guaranteed to be able to increase relfrozenxid unless
cancelled) before getting to the "emergency"-ish anti-wraparound state.
Or alternatively that we should have a separate threshold for the "harsher"
anti-wraparound measures.
> > > We now also collect LP_DEAD items in the dead_tuples array in the case
> > > where we cannot immediately get a cleanup lock on the buffer. We cannot
> > > prune without a cleanup lock, but opportunistic pruning may well have
> > > left some LP_DEAD items behind in the past -- no reason to miss those.
> >
> > This has become *much* more important with the changes around deciding when to
> > index vacuum. It's not just that opportunistic pruning could have left LP_DEAD
> > items, it's that a previous vacuum is quite likely to have left them there,
> > because the previous vacuum decided not to perform index cleanup.
>
> I haven't seen any evidence of that myself (with the optimization
> added to Postgres 14 by commit 5100010ee4). I still don't understand
> why you doubted that work so much. I'm not saying that you're wrong
> to; I'm saying that I don't think that I understand your perspective
> on it.
I didn't (nor do) doubt that it can be useful - to the contrary, I think the
unconditional index pass was a huge practial issue. I do however think that
there are cases where it can cause trouble. The comment above wasn't meant as
a criticism - just that it seems worth pointing out that one reason we might
encounter a lot of LP_DEAD items is previous vacuums that didn't perform index
cleanup.
> What I have seen in my own tests (particularly with BenchmarkSQL) is
> that most individual tables either never apply the optimization even
> once (because the table reliably has heap pages with many more LP_DEAD
> items than the 2%-of-relpages threshold), or will never need to
> (because there are precisely zero LP_DEAD items anyway). Remaining
> tables that *might* use the optimization tend to not go very long
> without actually getting a round of index vacuuming. It's just too
> easy for updates (and even aborted xact inserts) to introduce new
> LP_DEAD items for us to go long without doing index vacuuming.
I think workloads are a bit more worried than a realistic set of benchmarksk
that one person can run yourself.
I gave you examples of cases that I see as likely being bitten by this,
e.g. when the skipped index cleanup prevents IOS scans. When both the
likely-to-be-modified and likely-to-be-queried value ranges are a small subset
of the entire data, the 2% threshold can prevent vacuum from cleaning up
LP_DEAD entries for a long time. Or when all index scans are bitmap index
scans, and nothing ends up cleaning up the dead index entries in certain
ranges, and even an explicit vacuum doesn't fix the issue. Even a relatively
small rollback / non-HOT update rate can start to be really painful.
> > > Only VACUUM can mark these LP_DEAD items LP_UNUSED (no opportunistic
> > > technique is independently capable of cleaning up line pointer bloat),
> >
> > One thing we could do around this, btw, would be to aggressively replace
> > LP_REDIRECT items with their target item. We can't do that in all situations
> > (somebody might be following a ctid chain), but I think we have all the
> > information needed to do so. Probably would require a new HTSV RECENTLY_LIVE
> > state or something like that.
>
> Another idea is to truncate the line pointer during pruning (including
> opportunistic pruning). Matthias van de Meent has a patch for that.
I'm a bit doubtful that's as important (which is not to say that it's not
worth doing). For a heavily updated table the max space usage of the line
pointer array just isn't as big a factor as ending up with only half the
usable line pointers.
> > > Note that we no longer report on "pin skipped pages" in VACUUM VERBOSE,
> > > since there is no barely any real practical sense in which we actually
> > > miss doing useful work for these pages. Besides, this information
> > > always seemed to have little practical value, even to Postgres hackers.
> >
> > -0.5. I think it provides some value, and I don't see why the removal of the
> > information should be tied to this change. It's hard to diagnose why some dead
> > tuples aren't cleaned up - a common cause for that on smaller tables is that
> > nearly all pages are pinned nearly all the time.
>
> Is that still true, though? If it turns out that we need to leave it
> in, then I can do that. But I'd prefer to wait until we have more
> information before making a final decision. Remember, the high level
> idea of this whole patch is that we do as much work as possible for
> any scanned_pages, which now includes pages that we never successfully
> acquired a cleanup lock on. And so we're justified in assuming that
> they're exactly equivalent to pages that we did get a cleanup on --
> that's now the working assumption. I know that that's not literally
> true, but that doesn't mean it's not a useful fiction -- it should be
> very close to the truth.
IDK, it seems misleading to me. Small tables with a lot of churn - quite
common - are highly reliant on LP_DEAD entries getting removed or the tiny
table suddenly isn't so tiny anymore. And it's harder to diagnose why the
cleanup isn't happening without knowledge that pages needing cleanup couldn't
be cleaned up due to pins.
If you want to improve the logic so that we only count pages that would have
something to clean up, I'd be happy as well. It doesn't have to mean exactly
what it means today.
> > > + * NB: We must use orig_rel_pages, not vacrel->rel_pages, since we want
> > > + * the rel_pages used by lazy_scan_prune, from before a possible relation
> > > + * truncation took place. (vacrel->rel_pages is now new_rel_pages.)
> > > + */
> >
> > I think it should be doable to add an isolation test for this path. There have
> > been quite a few bugs around the wider topic...
>
> I would argue that we already have one -- vacuum-reltuples.spec. I had
> to update its expected output in the patch. I would argue that the
> behavioral change (count tuples on a pinned-by-cursor heap page) that
> necessitated updating the expected output for the test is an
> improvement overall.
I was thinking of truncations, which I don't think vacuum-reltuples.spec
tests.
> > > + {
> > > + /* Can safely advance relfrozen and relminmxid, too */
> > > + Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
> > > + orig_rel_pages);
> > > + vac_update_relstats(rel, new_rel_pages, new_live_tuples,
> > > + new_rel_allvisible, vacrel->nindexes > 0,
> > > + FreezeLimit, MultiXactCutoff, false);
> > > + }
> >
> > I wonder if this whole logic wouldn't become easier and less fragile if we
> > just went for maintaining the "actually observed" horizon while scanning the
> > relation. If we skip a page via VM set the horizon to invalid. Otherwise we
> > can keep track of the accurate horizon and use that. No need to count pages
> > and stuff.
>
> There is no question that that makes sense as an optimization -- my
> prototype convinced me of that already. But I don't think that it can
> simplify anything (not even the call to vac_update_relstats itself, to
> actually update relfrozenxid at the end).
Maybe. But we've had quite a few bugs because we ended up changing some detail
of what is excluded in one of the counters, leading to wrong determination
about whether we scanned everything or not.
> Fundamentally, this will only work if we decide to only skip all-frozen
> pages, which (by definition) only happens within aggressive VACUUMs.
Hm? Or if there's just no runs of all-visible pages of sufficient length, so
we don't end up skipping at all.
> You recently said (on the heap-pruning-14-bug thread) that you don't
> think it would be practical to always set a page all-frozen when we
> see that we're going to set it all-visible -- apparently you feel that
> we could never opportunistically freeze early such that all-visible
> but not all-frozen pages practically cease to exist. I'm still not
> sure why you believe that (though you may be right, or I might have
> misunderstood, since it's complicated).
Yes, I think it may not work out to do that. But it's not a very strongly held
opinion.
On reason for my doubt is the following:
We can set all-visible on a page without a FPW image (well, as long as hint
bits aren't logged). There's a significant difference between needing to WAL
log FPIs for every heap page or not, and it's not that rare for data to live
shorter than autovacuum_freeze_max_age or that limit never being reached.
On a table with 40 million individually inserted rows, fully hintbitted via
reads, I see a first VACUUM taking 1.6s and generating 11MB of WAL. A
subsequent VACUUM FREEZE takes 5s and generates 500MB of WAL. That's a quite
large multiplier...
If we ever managed to not have a per-page all-visible flag this'd get even
more extreme, because we'd then not even need to dirty the page for
insert-only pages. But if we want to freeze, we'd need to (unless we just got
rid of freezing).
> It would certainly benefit this dynamic relfrozenxid business if it was
> possible, though. If we could somehow make that work, then almost every
> VACUUM would be able to advance relfrozenxid, independently of
> aggressive-ness -- because we wouldn't have any
> all-visible-but-not-all-frozen pages to skip (that important detail wouldn't
> be left to chance).
Perhaps we can have most of the benefit even without that. If we were to
freeze whenever it didn't cause an additional FPWing, and perhaps didn't skip
all-visible but not !all-frozen pages if they were less than x% of the
to-be-scanned data, we should be able to to still increase relfrozenxid in a
lot of cases?
> > I don't particularly like doing BufferGetPage() before holding a lock on the
> > page. Perhaps I'm too influenced by rust etc, but ISTM that at some point it'd
> > be good to have a crosscheck that BufferGetPage() is only allowed when holding
> > a page level lock.
>
> I have occasionally wondered if the whole idea of reading heap pages
> with only a pin (and having cleanup locks in VACUUM) is really worth
> it -- alternative designs seem possible. Obviously that's a BIG
> discussion, and not one to have right now. But it seems kind of
> relevant.
With 'reading' do you mean reads-from-os, or just references to buffer
contents?
> Since it is often legit to read a heap page without a buffer lock
> (only a pin), I can't see why BufferGetPage() without a buffer lock
> shouldn't also be okay -- if anything it seems safer. I think that I
> would agree with you if it wasn't for that inconsistency (which is
> rather a big "if", to be sure -- even for me).
At least for heap it's rarely legit to read buffer contents via
BufferGetPage() without a lock. It's legit to read data at already-determined
offsets, but you can't look at much other than the tuple contents.
> > Why does it make sense to track DEAD tuples this way? Isn't that going to lead
> > to counting them over-and-over again? I think it's quite misleading to include
> > them in "dead bot not yet removable".
>
> Compared to what? Do we really want to invent a new kind of DEAD tuple
> (e.g., to report on), just to handle this rare case?
When looking at logs I use the
"tuples: %lld removed, %lld remain, %lld are dead but not yet removable, oldest xmin: %u\n"
line to see whether the user is likely to have issues around an old
transaction / slot / prepared xact preventing cleanup. If new_dead_tuples
doesn't identify those cases anymore that's not reliable anymore.
> I accept that this code is lying about the tuples being RECENTLY_DEAD,
> kind of. But isn't it still strictly closer to the truth, compared to
> HEAD? Counting it as RECENTLY_DEAD is far closer to the truth than not
> counting it at all.
I don't see how it's closer at all. There's imo a significant difference
between not being able to remove tuples because of the xmin horizon, and not
being able to remove it because we couldn't get a cleanup lock.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-11-24 01:01 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 2 replies; 72+ messages in thread
From: Peter Geoghegan @ 2021-11-24 01:01 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Masahiko Sawada <[email protected]>
On Mon, Nov 22, 2021 at 9:49 PM Andres Freund <[email protected]> wrote:
> > For example, we can definitely afford to wait a few more milliseconds
> > to get a cleanup lock just once
>
> We currently have no infrastructure to wait for an lwlock or pincount for a
> limited time. And at least for the former it'd not be easy to add. It may be
> worth adding that at some point, but I'm doubtful this is sufficient reason
> for nontrivial new infrastructure in very performance sensitive areas.
It was a hypothetical example. To be more practical about it: it seems
likely that we won't really benefit from waiting some amount of time
(not forever) for a cleanup lock in non-aggressive VACUUM, once we
have some of the relfrozenxid stuff we've talked about in place. In a
world where we're smarter about advancing relfrozenxid in
non-aggressive VACUUMs, the choice between waiting for a cleanup lock,
and not waiting (but also not advancing relfrozenxid at all) matters
less -- it's no longer a binary choice.
It's no longer a binary choice because we will have done away with the
current rigid way in which our new relfrozenxid for the relation is
either FreezeLimit, or nothing at all. So far we've only talked about
the case where we can update relfrozenxid with a value that happens to
be much newer than FreezeLimit. If we can do that, that's great. But
what about setting relfrozenxid to an *older* value than FreezeLimit
instead (in a non-aggressive VACUUM)? That's also pretty good! There
is still a decent chance that the final "suboptimal" relfrozenxid that
we determine can be safely set in pg_class at the end of our VACUUM
will still be far more recent than the preexisting relfrozenxid.
Especially with larger tables.
Advancing relfrozenxid should be thought of as a totally independent
thing to freezing tuples, at least in vacuumlazy.c itself. That's
kinda the case today, even, but *explicitly* decoupling advancing
relfrozenxid from actually freezing tuples seems like a good high
level goal for this project.
Remember, FreezeLimit is derived from vacuum_freeze_min_age in the
obvious way: OldestXmin for the VACUUM, minus vacuum_freeze_min_age
GUC/reloption setting. I'm pretty sure that this means that making
autovacuum freeze tuples more aggressively (by reducing
vacuum_freeze_min_age) could have the perverse effect of making
non-aggressive VACUUMs less likely to advance relfrozenxid -- which is
exactly backwards. This effect could easily be missed, even by expert
users, since there is no convenient instrumentation that shows how and
when relfrozenxid is advanced.
> > All of the autovacuums against the accounts table look similar to this
> > one -- you don't see anything about relfrozenxid being advanced
> > (because it isn't).
>> Does that really make
> > sense, though?
>
> Does what make really sense?
Well, my accounts table example wasn't a particularly good one (it was
a conveniently available example). I am now sure that you got the
point I was trying to make here already, based on what you go on to
say about non-aggressive VACUUMs optionally *not* skipping
all-visible-not-all-frozen heap pages in the hopes of advancing
relfrozenxid earlier (more on that idea below, in my response).
On reflection, the simplest way of expressing the same idea is what I
just said about decoupling (decoupling advancing relfrozenxid from
freezing).
> I think pgbench_accounts is just a really poor showcase. Most importantly
> there's no even slightly longer running transactions that hold down the xid
> horizon. But in real workloads thats incredibly common IME. It's also quite
> uncommon in real workloads to huge tables in which all records are
> updated. It's more common to have value ranges that are nearly static, and a
> more heavily changing range.
I agree.
> I think the most interesting cases where using the "measured" horizon will be
> advantageous is anti-wrap vacuums. Those obviously have to happen for rarely
> modified tables, including completely static ones, too. Using the "measured"
> horizon will allow us to reduce the frequency of anti-wrap autovacuums on old
> tables, because we'll be able to set a much more recent relfrozenxid.
That's probably true in practice -- but who knows these days, with the
autovacuum_vacuum_insert_scale_factor stuff? Either way I see no
reason to emphasize that case in the design itself. The "decoupling"
concept now seems like the key design-level concept -- everything else
follows naturally from that.
> This is becoming more common with the increased use of partitioning.
Also with bulk loading. There could easily be a tiny number of
distinct XIDs that are close together in time, for many many rows --
practically one XID, or even exactly one XID.
> No, not quite. We treat anti-wraparound vacuums as an emergency (including
> logging messages, not cancelling). But the only mechanism we have against
> anti-wrap vacuums happening is vacuum_freeze_table_age. But as you say, that's
> not really a "real" mechanism, because it requires an "independent" reason to
> vacuum a table.
Got it.
> I've seen cases where anti-wraparound vacuums weren't a problem / never
> happend for important tables for a long time, because there always was an
> "independent" reason for autovacuum to start doing its thing before the table
> got to be autovacuum_freeze_max_age old. But at some point the important
> tables started to be big enough that autovacuum didn't schedule vacuums that
> got promoted to aggressive via vacuum_freeze_table_age before the anti-wrap
> vacuums.
Right. Not just because they were big; also because autovacuum runs at
geometric intervals -- the final reltuples from last time is used to
determine the point at which av runs this time. This might make sense,
or it might not make any sense -- it all depends (mostly on index
stuff).
> Then things started to burn, because of the unpaced anti-wrap vacuums
> clogging up all IO, or maybe it was the vacuums not cancelling - I don't quite
> remember the details.
Non-cancelling anti-wraparound VACUUMs that (all of a sudden) cause
chaos because they interact badly with automated DDL is one I've seen
several times -- I'm sure you have too. That was what the Manta/Joyent
blogpost I referenced upthread went into.
> Behaviour that lead to a "sudden" falling over, rather than getting gradually
> worse are bad - they somehow tend to happen on Friday evenings :).
These are among our most important challenges IMV.
> Just that autovacuum should have a mechanism to trigger aggressive vacuums
> (i.e. ones that are guaranteed to be able to increase relfrozenxid unless
> cancelled) before getting to the "emergency"-ish anti-wraparound state.
Maybe, but that runs into the problem of needing another GUC that
nobody will ever be able to remember the name of. I consider the idea
of adding a variety of measures that make non-aggressive VACUUM much
more likely to advance relfrozenxid in practice to be far more
promising.
> Or alternatively that we should have a separate threshold for the "harsher"
> anti-wraparound measures.
Or maybe just raise the default of autovacuum_freeze_max_age, which
many people don't change? That might be a lot safer than it once was.
Or will be, once we manage to teach VACUUM to advance relfrozenxid
more often in non-aggressive VACUUMs on Postgres 15. Imagine a world
in which we have that stuff in place, as well as related enhancements
added in earlier releases: autovacuum_vacuum_insert_scale_factor, the
freezemap, and the wraparound failsafe.
These add up to a lot; with all of that in place, the risk we'd be
introducing by increasing the default value of
autovacuum_freeze_max_age would be *far* lower than the risk of making
the same change back in 2006. I bring up 2006 because it was the year
that commit 48188e1621 added autovacuum_freeze_max_age -- the default
hasn't changed since that time.
> I think workloads are a bit more worried than a realistic set of benchmarksk
> that one person can run yourself.
No question. I absolutely accept that I only have to miss one
important detail with something like this -- that just goes with the
territory. Just saying that I have yet to see any evidence that the
bypass-indexes behavior really hurt anything. I do take the idea that
I might have missed something very seriously, despite all this.
> I gave you examples of cases that I see as likely being bitten by this,
> e.g. when the skipped index cleanup prevents IOS scans. When both the
> likely-to-be-modified and likely-to-be-queried value ranges are a small subset
> of the entire data, the 2% threshold can prevent vacuum from cleaning up
> LP_DEAD entries for a long time. Or when all index scans are bitmap index
> scans, and nothing ends up cleaning up the dead index entries in certain
> ranges, and even an explicit vacuum doesn't fix the issue. Even a relatively
> small rollback / non-HOT update rate can start to be really painful.
That does seem possible. But I consider it very unlikely to appear as
a regression caused by the bypass mechanism itself -- not in any way
that was consistent over time. As far as I can tell, autovacuum
scheduling just doesn't operate at that level of precision, and never
has.
I have personally observed that ANALYZE does a very bad job at
noticing LP_DEAD items in tables/workloads where LP_DEAD items (not
DEAD tuples) tend to concentrate [1]. The whole idea that ANALYZE
should count these items as if they were normal tuples seems pretty
bad to me.
Put it this way: imagine you run into trouble with the bypass thing,
and then you opt to disable it on that table (using the INDEX_CLEANUP
reloption). Why should this step solve the problem on its own? In
order for that to work, VACUUM would have to have to know to be very
aggressive about these LP_DEAD items. But there is good reason to
believe that it just won't ever notice them, as long as ANALYZE is
expected to provide reliable statistics that drive autovacuum --
they're just too concentrated for the block-based approach to truly
work.
I'm not minimizing the risk. Just telling you my thoughts on this.
> I'm a bit doubtful that's as important (which is not to say that it's not
> worth doing). For a heavily updated table the max space usage of the line
> pointer array just isn't as big a factor as ending up with only half the
> usable line pointers.
Agreed; by far the best chance we have of improving the line pointer
bloat situation is preventing it in the first place, by increasing
MaxHeapTuplesPerPage. Once we actually do that, our remaining options
are going to be much less helpful -- then it really is mostly just up
to VACUUM.
> And it's harder to diagnose why the
> cleanup isn't happening without knowledge that pages needing cleanup couldn't
> be cleaned up due to pins.
>
> If you want to improve the logic so that we only count pages that would have
> something to clean up, I'd be happy as well. It doesn't have to mean exactly
> what it means today.
It seems like what you really care about here are remaining cases
where our inability to acquire a cleanup lock has real consequences --
you want to hear about it when it happens, however unlikely it may be.
In other words, you want to keep something in log_autovacuum_* that
indicates that "less than the expected amount of work was completed"
due to an inability to acquire a cleanup lock. And so for you, this is
a question of keeping instrumentation that might still be useful, not
a question of how we define things fundamentally, at the design level.
Sound right?
If so, then this proposal might be acceptable to you:
* Remaining DEAD tuples with storage (though not LP_DEAD items from
previous opportunistic pruning) will get counted separately in the
lazy_scan_noprune (no cleanup lock) path. Also count the total number
of distinct pages that were found to contain one or more such DEAD
tuples.
* These two new counters will be reported on their own line in the log
output, though only in the cases where we actually have any such
tuples -- which will presumably be much rarer than simply failing to
get a cleanup lock (that's now no big deal at all, because we now
consistently do certain cleanup steps, and because FreezeLimit isn't
the only viable thing that we can set relfrozenxid to, at least in the
non-aggressive case).
* There is still a limited sense in which the same items get counted
as RECENTLY_DEAD -- though just those aspects that make the overall
design simpler. So the helpful aspects of this are still preserved.
We only need to tell pgstat_report_vacuum() that these items are
"deadtuples" (remaining dead tuples). That can work by having its
caller add a new int64 counter (same new tuple-based counter used for
the new log line) to vacrel->new_dead_tuples. We'd also add the same
new tuple counter in about the same way at the point where we
determine a final vacrel->new_rel_tuples.
So we wouldn't really be treating anything as RECENTLY_DEAD anymore --
pgstat_report_vacuum() and vacrel->new_dead_tuples don't specifically
expect anything about RECENTLY_DEAD-ness already.
> I was thinking of truncations, which I don't think vacuum-reltuples.spec
> tests.
Got it. I'll look into that for v2.
> Maybe. But we've had quite a few bugs because we ended up changing some detail
> of what is excluded in one of the counters, leading to wrong determination
> about whether we scanned everything or not.
Right. But let me just point out that my whole approach is to make
that impossible, by not needing to count pages, except in
scanned_pages (and in frozenskipped_pages + rel_pages). The processing
performed for any page that we actually read during VACUUM should be
uniform (or practically uniform), by definition. With minimal fudging
in the cleanup lock case (because we mostly do the same work there
too).
There should be no reason for any more page counters now, except for
non-critical instrumentation. For example, if you want to get the
total number of pages skipped via the visibility map (not just
all-frozen pages), then you simply subtract scanned_pages from
rel_pages.
> > Fundamentally, this will only work if we decide to only skip all-frozen
> > pages, which (by definition) only happens within aggressive VACUUMs.
>
> Hm? Or if there's just no runs of all-visible pages of sufficient length, so
> we don't end up skipping at all.
Of course. But my point was: who knows when that'll happen?
> On reason for my doubt is the following:
>
> We can set all-visible on a page without a FPW image (well, as long as hint
> bits aren't logged). There's a significant difference between needing to WAL
> log FPIs for every heap page or not, and it's not that rare for data to live
> shorter than autovacuum_freeze_max_age or that limit never being reached.
This sounds like an objection to one specific heuristic, and not an
objection to the general idea. The only essential part is
"opportunistic freezing during vacuum, when the cost is clearly very
low, and the benefit is probably high". And so it now seems you were
making a far more limited statement than I first believed.
Obviously many variations are possible -- there is a spectrum.
Example: a heuristic that makes VACUUM notice when it is going to
freeze at least one tuple on a page, iff the page will be marked
all-visible in any case -- we should instead freeze every tuple on the
page, and mark the page all-frozen, batching work (could account for
LP_DEAD items here too, not counting them on the assumption that
they'll become LP_UNUSED during the second heap pass later on).
If we see these conditions, then the likely explanation is that the
tuples on the heap page happen to have XIDs that are "split" by the
not-actually-important FreezeLimit cutoff, despite being essentially
similar in any way that matters.
If you want to make the same heuristic more conservative: only do this
when no existing tuples are frozen, since that could be taken as a
sign of the original heuristic not quite working on the same heap page
at an earlier stage.
I suspect that even very conservative versions of the same basic idea
would still help a lot.
> Perhaps we can have most of the benefit even without that. If we were to
> freeze whenever it didn't cause an additional FPWing, and perhaps didn't skip
> all-visible but not !all-frozen pages if they were less than x% of the
> to-be-scanned data, we should be able to to still increase relfrozenxid in a
> lot of cases?
I bet that's true. I like that idea.
If we had this policy, then the number of "extra"
visited-in-non-aggressive-vacuum pages (all-visible but not yet
all-frozen pages) could be managed over time through more
opportunistic freezing. This might make it work even better.
These all-visible (but not all-frozen) heap pages could be considered
"tenured", since they have survived at least one full VACUUM cycle
without being unset. So why not also freeze them based on the
assumption that they'll probably stay that way forever? There won't be
so many of the pages when we do this anyway, by definition -- since
we'd have a heuristic that limited the total number (say to no more
than 10% of the total relation size, something like that).
We're smoothing out the work that currently takes place all together
during an aggressive VACUUM this way.
Moreover, there is perhaps a good chance that the total number of
all-visible-not all-frozen heap pages will *stay* low over time, as a
result of this policy actually working -- there may be a virtuous
cycle that totally prevents us from getting an aggressive VACUUM even
once.
> > I have occasionally wondered if the whole idea of reading heap pages
> > with only a pin (and having cleanup locks in VACUUM) is really worth
> > it -- alternative designs seem possible. Obviously that's a BIG
> > discussion, and not one to have right now. But it seems kind of
> > relevant.
>
> With 'reading' do you mean reads-from-os, or just references to buffer
> contents?
The latter.
[1] https://postgr.es/m/CAH2-Wz=9R83wcwZcPUH4FVPeDM4znzbzMvp3rt21+XhQWMU8+g@mail.gmail.com
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-11-24 01:32 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
1 sibling, 0 replies; 72+ messages in thread
From: Andres Freund @ 2021-11-24 01:32 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Masahiko Sawada <[email protected]>
Hi,
On 2021-11-23 17:01:20 -0800, Peter Geoghegan wrote:
> > On reason for my doubt is the following:
> >
> > We can set all-visible on a page without a FPW image (well, as long as hint
> > bits aren't logged). There's a significant difference between needing to WAL
> > log FPIs for every heap page or not, and it's not that rare for data to live
> > shorter than autovacuum_freeze_max_age or that limit never being reached.
>
> This sounds like an objection to one specific heuristic, and not an
> objection to the general idea.
I understood you to propose that we do not have separate frozen and
all-visible states. Which I think will be problematic, because of scenarios
like the above.
> The only essential part is "opportunistic freezing during vacuum, when the
> cost is clearly very low, and the benefit is probably high". And so it now
> seems you were making a far more limited statement than I first believed.
I'm on board with freezing when we already dirty out the page, and when doing
so doesn't cause an additional FPI. And I don't think I've argued against that
in the past.
> These all-visible (but not all-frozen) heap pages could be considered
> "tenured", since they have survived at least one full VACUUM cycle
> without being unset. So why not also freeze them based on the
> assumption that they'll probably stay that way forever?
Because it's a potentially massive increase in write volume? E.g. if you have
a insert-only workload, and you discard old data by dropping old partitions,
this will often add yet another rewrite, despite your data likely never
getting old enough to need to be frozen.
Given that we often immediately need to start another vacuum just when one
finished, because the vacuum took long enough to reach thresholds of vacuuming
again, I don't think the (auto-)vacuum count is a good proxy.
Maybe you meant this as a more limited concept, i.e. only doing so when the
percentage of all-visible but not all-frozen pages is small?
We could perhaps do better with if we had information about the system-wide
rate of xid throughput and how often / how long past vacuums of a table took.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-11-30 19:52 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
1 sibling, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2021-11-30 19:52 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Masahiko Sawada <[email protected]>
On Tue, Nov 23, 2021 at 5:01 PM Peter Geoghegan <[email protected]> wrote:
> > Behaviour that lead to a "sudden" falling over, rather than getting gradually
> > worse are bad - they somehow tend to happen on Friday evenings :).
>
> These are among our most important challenges IMV.
I haven't had time to work through any of your feedback just yet --
though it's certainly a priority for. I won't get to it until I return
home from PGConf NYC next week.
Even still, here is a rebased v2, just to fix the bitrot. This is just
a courtesy to anybody interested in the patch.
--
Peter Geoghegan
Attachments:
[application/octet-stream] v2-0001-Simplify-lazy_scan_heap-s-handling-of-scanned-pag.patch (44.2K, ../../CAH2-WznjeDf5i8e3vsjxhmG8qCb9wNXi6Eg38XCsGsFOZfWYFA@mail.gmail.com/2-v2-0001-Simplify-lazy_scan_heap-s-handling-of-scanned-pag.patch)
download | inline diff:
From 2cc761a55b6f727b44a32b03e8393ffd3f61fb2c Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Wed, 17 Nov 2021 21:27:06 -0800
Subject: [PATCH v2] Simplify lazy_scan_heap's handling of scanned pages.
Redefine a scanned page as any heap page that actually gets pinned by
VACUUM's first pass over the heap. Pages counted by scanned_pages are
now the complement of the pages that are skipped over using the
visibility map. This new definition significantly simplifies quite a
few things.
Now heap relation truncation, visibility map bit setting, tuple counting
(e.g., for pg_class.reltuples), and tuple freezing all share a common
definition of scanned_pages. That makes it possible to remove certain
special cases, that never made much sense. We no longer need to track
tupcount_pages separately (see bugfix commit 1914c5ea for details),
since we now always count tuples from pages that are scanned_pages. We
also don't need to needlessly distinguish between aggressive and
non-aggressive VACUUM operations when we cannot immediately acquire a
cleanup lock.
Since any VACUUM (not just an aggressive VACUUM) can sometimes advance
relfrozenxid, we now make non-aggressive VACUUMs work just a little
harder in order to make that desirable outcome more likely in practice.
Aggressive VACUUMs have long checked contended pages with only a shared
lock, to avoid needlessly waiting on a cleanup lock (in the common case
where the contended page has no tuples that need to be frozen anyway).
We still don't make non-aggressive VACUUMs wait for a cleanup lock, of
course -- if we did that they'd no longer be non-aggressive. But we now
make the non-aggressive case notice that a failure to acquire a cleanup
lock on one particular heap page does not in itself make it unsafe to
advance relfrozenxid for the whole relation (which is what we usually
see in the aggressive case already).
This new relfrozenxid optimization might not be all that valuable on its
own, but it may still facilitate future work that makes non-aggressive
VACUUMs more conscious of the benefit of advancing relfrozenxid sooner
rather than later. In general it would be useful for non-aggressive
VACUUMs to be "more aggressive" opportunistically (e.g., by waiting for
a cleanup lock once or twice if needed). It would also be generally
useful if aggressive VACUUMs were "less aggressive" opportunistically
(e.g. by being responsive to query cancellations when the risk of
wraparound failure is still very low).
We now also collect LP_DEAD items in the dead_tuples array in the case
where we cannot immediately get a cleanup lock on the buffer. We cannot
prune without a cleanup lock, but opportunistic pruning may well have
left some LP_DEAD items behind in the past -- no reason to miss those.
Only VACUUM can mark these LP_DEAD items LP_UNUSED (no opportunistic
technique is independently capable of cleaning up line pointer bloat),
so we should not squander any opportunity to do that. Commit 8523492d4e
taught VACUUM to set LP_DEAD line pointers to LP_UNUSED while only
holding an exclusive lock (not a cleanup lock), so we can expect to set
existing LP_DEAD items to LP_UNUSED reliably, even when we cannot
acquire our own cleanup lock at either pass over the heap (unless we opt
to skip index vacuuming, which implies that there is no second pass over
the heap).
Note that we no longer report on "pin skipped pages" in VACUUM VERBOSE,
since there is no barely any real practical sense in which we actually
miss doing useful work for these pages. Besides, this information
always seemed to have little practical value, even to Postgres hackers.
---
src/backend/access/heap/vacuumlazy.c | 792 +++++++++++-------
.../isolation/expected/vacuum-reltuples.out | 2 +-
.../isolation/specs/vacuum-reltuples.spec | 7 +-
3 files changed, 500 insertions(+), 301 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 282b44f87..39a7fb39e 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -284,6 +284,8 @@ typedef struct LVRelState
Relation *indrels;
int nindexes;
+ /* Aggressive VACUUM (scan all unfrozen pages)? */
+ bool aggressive;
/* Wraparound failsafe has been triggered? */
bool failsafe_active;
/* Consider index vacuuming bypass optimization? */
@@ -308,6 +310,8 @@ typedef struct LVRelState
/* VACUUM operation's cutoff for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
+ /* Are FreezeLimit/MultiXactCutoff still valid? */
+ bool freeze_cutoffs_valid;
/* Error reporting state */
char *relnamespace;
@@ -322,10 +326,8 @@ typedef struct LVRelState
*/
LVDeadItems *dead_items; /* TIDs whose index tuples we'll delete */
BlockNumber rel_pages; /* total number of pages */
- BlockNumber scanned_pages; /* number of pages we examined */
- BlockNumber pinskipped_pages; /* # of pages skipped due to a pin */
- BlockNumber frozenskipped_pages; /* # of frozen pages we skipped */
- BlockNumber tupcount_pages; /* pages whose tuples we counted */
+ BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
+ BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber pages_removed; /* pages remove by truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber nonempty_pages; /* actually, last nonempty page + 1 */
@@ -338,6 +340,7 @@ typedef struct LVRelState
/* Instrumentation counters */
int num_index_scans;
+ /* Counters that follow are only for scanned_pages */
int64 tuples_deleted; /* # deleted from table */
int64 lpdead_items; /* # deleted from indexes */
int64 new_dead_tuples; /* new estimated total # of dead items in
@@ -377,19 +380,22 @@ static int elevel = -1;
/* non-export function prototypes */
-static void lazy_scan_heap(LVRelState *vacrel, VacuumParams *params,
- bool aggressive);
+static void lazy_scan_heap(LVRelState *vacrel, VacuumParams *params);
+static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf,
+ BlockNumber blkno, Page page,
+ bool sharelock, Buffer vmbuffer);
static void lazy_scan_prune(LVRelState *vacrel, Buffer buf,
BlockNumber blkno, Page page,
GlobalVisState *vistest,
LVPagePruneState *prunestate);
+static bool lazy_scan_noprune(LVRelState *vacrel, Buffer buf,
+ BlockNumber blkno, Page page,
+ bool *hastup);
static void lazy_vacuum(LVRelState *vacrel);
static bool lazy_vacuum_all_indexes(LVRelState *vacrel);
static void lazy_vacuum_heap_rel(LVRelState *vacrel);
static int lazy_vacuum_heap_page(LVRelState *vacrel, BlockNumber blkno,
Buffer buffer, int index, Buffer *vmbuffer);
-static bool lazy_check_needs_freeze(Buffer buf, bool *hastup,
- LVRelState *vacrel);
static bool lazy_check_wraparound_failsafe(LVRelState *vacrel);
static void do_parallel_lazy_vacuum_all_indexes(LVRelState *vacrel);
static void do_parallel_lazy_cleanup_all_indexes(LVRelState *vacrel);
@@ -465,16 +471,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
int usecs;
double read_rate,
write_rate;
- bool aggressive; /* should we scan all unfrozen pages? */
- bool scanned_all_unfrozen; /* actually scanned all such pages? */
+ bool aggressive;
+ BlockNumber orig_rel_pages;
char **indnames = NULL;
TransactionId xidFullScanLimit;
MultiXactId mxactFullScanLimit;
BlockNumber new_rel_pages;
BlockNumber new_rel_allvisible;
double new_live_tuples;
- TransactionId new_frozen_xid;
- MultiXactId new_min_multi;
ErrorContextCallback errcallback;
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
@@ -529,6 +533,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->rel = rel;
vac_open_indexes(vacrel->rel, RowExclusiveLock, &vacrel->nindexes,
&vacrel->indrels);
+ vacrel->aggressive = aggressive;
vacrel->failsafe_active = false;
vacrel->consider_bypass_optimization = true;
@@ -573,6 +578,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->OldestXmin = OldestXmin;
vacrel->FreezeLimit = FreezeLimit;
vacrel->MultiXactCutoff = MultiXactCutoff;
+ /* Track if cutoffs became invalid (possible in !aggressive case only) */
+ vacrel->freeze_cutoffs_valid = true;
vacrel->relnamespace = get_namespace_name(RelationGetNamespace(rel));
vacrel->relname = pstrdup(RelationGetRelationName(rel));
@@ -609,30 +616,16 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* Call lazy_scan_heap to perform all required heap pruning, index
* vacuuming, and heap vacuuming (plus related processing)
*/
- lazy_scan_heap(vacrel, params, aggressive);
+ lazy_scan_heap(vacrel, params);
/* Done with indexes */
vac_close_indexes(vacrel->nindexes, vacrel->indrels, NoLock);
/*
- * Compute whether we actually scanned the all unfrozen pages. If we did,
- * we can adjust relfrozenxid and relminmxid.
- *
- * NB: We need to check this before truncating the relation, because that
- * will change ->rel_pages.
- */
- if ((vacrel->scanned_pages + vacrel->frozenskipped_pages)
- < vacrel->rel_pages)
- {
- Assert(!aggressive);
- scanned_all_unfrozen = false;
- }
- else
- scanned_all_unfrozen = true;
-
- /*
- * Optionally truncate the relation.
+ * Optionally truncate the relation. But remember the relation size used
+ * by lazy_scan_prune for later first.
*/
+ orig_rel_pages = vacrel->rel_pages;
if (should_attempt_truncation(vacrel))
{
/*
@@ -663,28 +656,43 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
*
* For safety, clamp relallvisible to be not more than what we're setting
* relpages to.
- *
- * Also, don't change relfrozenxid/relminmxid if we skipped any pages,
- * since then we don't know for certain that all tuples have a newer xmin.
*/
- new_rel_pages = vacrel->rel_pages;
+ new_rel_pages = vacrel->rel_pages; /* After possible rel truncation */
new_live_tuples = vacrel->new_live_tuples;
visibilitymap_count(rel, &new_rel_allvisible, NULL);
if (new_rel_allvisible > new_rel_pages)
new_rel_allvisible = new_rel_pages;
- new_frozen_xid = scanned_all_unfrozen ? FreezeLimit : InvalidTransactionId;
- new_min_multi = scanned_all_unfrozen ? MultiXactCutoff : InvalidMultiXactId;
-
- vac_update_relstats(rel,
- new_rel_pages,
- new_live_tuples,
- new_rel_allvisible,
- vacrel->nindexes > 0,
- new_frozen_xid,
- new_min_multi,
- false);
+ /*
+ * Aggressive VACUUM (which is the same thing as anti-wraparound
+ * autovacuum for most practical purposes) exists so that we'll reliably
+ * advance relfrozenxid and relminmxid sooner or later. But we can often
+ * opportunistically advance them even in a non-aggressive VACUUM.
+ * Consider if that's possible now.
+ *
+ * NB: We must use orig_rel_pages, not vacrel->rel_pages, since we want
+ * the rel_pages used by lazy_scan_prune, from before a possible relation
+ * truncation took place. (vacrel->rel_pages is now new_rel_pages.)
+ */
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
+ !vacrel->freeze_cutoffs_valid)
+ {
+ /* Cannot advance relfrozenxid/relminmxid -- just update pg_class */
+ Assert(!aggressive);
+ vac_update_relstats(rel, new_rel_pages, new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ InvalidTransactionId, InvalidMultiXactId, false);
+ }
+ else
+ {
+ /* Can safely advance relfrozen and relminmxid, too */
+ Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
+ orig_rel_pages);
+ vac_update_relstats(rel, new_rel_pages, new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ FreezeLimit, MultiXactCutoff, false);
+ }
/*
* Report results to the stats collector, too.
@@ -713,7 +721,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
StringInfoData buf;
char *msgfmt;
- BlockNumber orig_rel_pages;
TimestampDifference(starttime, endtime, &secs, &usecs);
@@ -760,10 +767,9 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->relnamespace,
vacrel->relname,
vacrel->num_index_scans);
- appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped due to pins, %u skipped frozen\n"),
+ appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped frozen\n"),
vacrel->pages_removed,
vacrel->rel_pages,
- vacrel->pinskipped_pages,
vacrel->frozenskipped_pages);
appendStringInfo(&buf,
_("tuples: %lld removed, %lld remain, %lld are dead but not yet removable, oldest xmin: %u\n"),
@@ -771,7 +777,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
(long long) vacrel->new_rel_tuples,
(long long) vacrel->new_dead_tuples,
OldestXmin);
- orig_rel_pages = vacrel->rel_pages + vacrel->pages_removed;
if (orig_rel_pages > 0)
{
if (vacrel->do_index_vacuuming)
@@ -888,9 +893,10 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* supply.
*/
static void
-lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
+lazy_scan_heap(LVRelState *vacrel, VacuumParams *params)
{
LVDeadItems *dead_items;
+ bool aggressive;
BlockNumber nblocks,
blkno,
next_unskippable_block,
@@ -910,26 +916,14 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pg_rusage_init(&ru0);
- if (aggressive)
- ereport(elevel,
- (errmsg("aggressively vacuuming \"%s.%s\"",
- vacrel->relnamespace,
- vacrel->relname)));
- else
- ereport(elevel,
- (errmsg("vacuuming \"%s.%s\"",
- vacrel->relnamespace,
- vacrel->relname)));
-
+ aggressive = vacrel->aggressive;
nblocks = RelationGetNumberOfBlocks(vacrel->rel);
next_unskippable_block = 0;
next_failsafe_block = 0;
next_fsm_block_to_vacuum = 0;
vacrel->rel_pages = nblocks;
vacrel->scanned_pages = 0;
- vacrel->pinskipped_pages = 0;
vacrel->frozenskipped_pages = 0;
- vacrel->tupcount_pages = 0;
vacrel->pages_removed = 0;
vacrel->lpdead_item_pages = 0;
vacrel->nonempty_pages = 0;
@@ -947,6 +941,17 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
vacrel->indstats = (IndexBulkDeleteResult **)
palloc0(vacrel->nindexes * sizeof(IndexBulkDeleteResult *));
+ if (aggressive)
+ ereport(elevel,
+ (errmsg("aggressively vacuuming \"%s.%s\"",
+ vacrel->relnamespace,
+ vacrel->relname)));
+ else
+ ereport(elevel,
+ (errmsg("vacuuming \"%s.%s\"",
+ vacrel->relnamespace,
+ vacrel->relname)));
+
/*
* Do failsafe precheck before calling dead_items_alloc. This ensures
* that parallel VACUUM won't be attempted when relfrozenxid is already
@@ -1002,15 +1007,6 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* just added to that page are necessarily newer than the GlobalXmin we
* computed, so they'll have no effect on the value to which we can safely
* set relfrozenxid. A similar argument applies for MXIDs and relminmxid.
- *
- * We will scan the table's last page, at least to the extent of
- * determining whether it has tuples or not, even if it should be skipped
- * according to the above rules; except when we've already determined that
- * it's not worth trying to truncate the table. This avoids having
- * lazy_truncate_heap() take access-exclusive lock on the table to attempt
- * a truncation that just fails immediately because there are tuples in
- * the last page. This is worth avoiding mainly because such a lock must
- * be replayed on any hot standby, where it can be disruptive.
*/
if ((params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0)
{
@@ -1048,18 +1044,14 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
bool all_visible_according_to_vm = false;
LVPagePruneState prunestate;
- /*
- * Consider need to skip blocks. See note above about forcing
- * scanning of last page.
- */
-#define FORCE_CHECK_PAGE() \
- (blkno == nblocks - 1 && should_attempt_truncation(vacrel))
-
pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
blkno, InvalidOffsetNumber);
+ /*
+ * Consider need to skip blocks
+ */
if (blkno == next_unskippable_block)
{
/* Time to advance next_unskippable_block */
@@ -1108,13 +1100,19 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
else
{
/*
- * The current block is potentially skippable; if we've seen a
- * long enough run of skippable blocks to justify skipping it, and
- * we're not forced to check it, then go ahead and skip.
- * Otherwise, the page must be at least all-visible if not
- * all-frozen, so we can set all_visible_according_to_vm = true.
+ * The current block can be skipped if we've seen a long enough
+ * run of skippable blocks to justify skipping it.
+ *
+ * There is an exception: we will scan the table's last page to
+ * determine whether it has tuples or not, even if it would
+ * otherwise be skipped (unless it's clearly not worth trying to
+ * truncate the table). This avoids having lazy_truncate_heap()
+ * take access-exclusive lock on the table to attempt a truncation
+ * that just fails immediately because there are tuples in the
+ * last page.
*/
- if (skipping_blocks && !FORCE_CHECK_PAGE())
+ if (skipping_blocks &&
+ !(blkno == nblocks - 1 && should_attempt_truncation(vacrel)))
{
/*
* Tricky, tricky. If this is in aggressive vacuum, the page
@@ -1124,12 +1122,22 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* case, or else we'll think we can't update relfrozenxid and
* relminmxid. If it's not an aggressive vacuum, we don't
* know whether it was all-frozen, so we have to recheck; but
- * in this case an approximate answer is OK.
+ * in this case an approximate answer is still correct.
+ *
+ * (We really don't want to miss out on the opportunity to
+ * advance relfrozenxid in a non-aggressive vacuum, but this
+ * edge case shouldn't make that appreciably less likely in
+ * practice.)
*/
if (aggressive || VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
vacrel->frozenskipped_pages++;
continue;
}
+
+ /*
+ * Otherwise, the page must be at least all-visible if not
+ * all-frozen, so we can set all_visible_according_to_vm = true
+ */
all_visible_according_to_vm = true;
}
@@ -1154,7 +1162,8 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* Consider if we definitely have enough space to process TIDs on page
* already. If we are close to overrunning the available space for
* dead_items TIDs, pause and do a cycle of vacuuming before we tackle
- * this page.
+ * this page. Must do this before calling lazy_scan_prune (or before
+ * calling lazy_scan_noprune).
*/
Assert(dead_items->max_items >= MaxHeapTuplesPerPage);
if (dead_items->max_items - dead_items->num_items < MaxHeapTuplesPerPage)
@@ -1189,7 +1198,8 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
}
/*
- * Set up visibility map page as needed.
+ * Set up visibility map page as needed, and pin the heap page that
+ * we're going to scan.
*
* Pin the visibility map page in case we need to mark the page
* all-visible. In most cases this will be very cheap, because we'll
@@ -1202,156 +1212,52 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
buf = ReadBufferExtended(vacrel->rel, MAIN_FORKNUM, blkno,
RBM_NORMAL, vacrel->bstrategy);
+ page = BufferGetPage(buf);
+ vacrel->scanned_pages++;
/*
- * We need buffer cleanup lock so that we can prune HOT chains and
- * defragment the page.
+ * We need a buffer cleanup lock to prune HOT chains and defragment
+ * the page in lazy_scan_prune. But when it's not possible to acquire
+ * a cleanup lock right away, we may be able to settle for reduced
+ * processing in lazy_scan_noprune.
*/
if (!ConditionalLockBufferForCleanup(buf))
{
bool hastup;
- /*
- * If we're not performing an aggressive scan to guard against XID
- * wraparound, and we don't want to forcibly check the page, then
- * it's OK to skip vacuuming pages we get a lock conflict on. They
- * will be dealt with in some future vacuum.
- */
- if (!aggressive && !FORCE_CHECK_PAGE())
+ LockBuffer(buf, BUFFER_LOCK_SHARE);
+
+ /* Check for new or empty pages before lazy_scan_noprune call */
+ if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, true,
+ vmbuffer))
{
- ReleaseBuffer(buf);
- vacrel->pinskipped_pages++;
+ /* Lock and pin released for us */
+ continue;
+ }
+
+ if (lazy_scan_noprune(vacrel, buf, blkno, page, &hastup))
+ {
+ /* No need to wait for cleanup lock for this page */
+ UnlockReleaseBuffer(buf);
+ if (hastup)
+ vacrel->nonempty_pages = blkno + 1;
continue;
}
/*
- * Read the page with share lock to see if any xids on it need to
- * be frozen. If not we just skip the page, after updating our
- * scan statistics. If there are some, we wait for cleanup lock.
- *
- * We could defer the lock request further by remembering the page
- * and coming back to it later, or we could even register
- * ourselves for multiple buffers and then service whichever one
- * is received first. For now, this seems good enough.
- *
- * If we get here with aggressive false, then we're just forcibly
- * checking the page, and so we don't want to insist on getting
- * the lock; we only need to know if the page contains tuples, so
- * that we can update nonempty_pages correctly. It's convenient
- * to use lazy_check_needs_freeze() for both situations, though.
+ * lazy_scan_noprune could not do all required processing without
+ * a cleanup lock. Wait for a cleanup lock, and then proceed to
+ * lazy_scan_prune to perform ordinary pruning and freezing.
*/
- LockBuffer(buf, BUFFER_LOCK_SHARE);
- if (!lazy_check_needs_freeze(buf, &hastup, vacrel))
- {
- UnlockReleaseBuffer(buf);
- vacrel->scanned_pages++;
- vacrel->pinskipped_pages++;
- if (hastup)
- vacrel->nonempty_pages = blkno + 1;
- continue;
- }
- if (!aggressive)
- {
- /*
- * Here, we must not advance scanned_pages; that would amount
- * to claiming that the page contains no freezable tuples.
- */
- UnlockReleaseBuffer(buf);
- vacrel->pinskipped_pages++;
- if (hastup)
- vacrel->nonempty_pages = blkno + 1;
- continue;
- }
+ Assert(vacrel->aggressive);
LockBuffer(buf, BUFFER_LOCK_UNLOCK);
LockBufferForCleanup(buf);
- /* drop through to normal processing */
}
- /*
- * By here we definitely have enough dead_items space for whatever
- * LP_DEAD tids are on this page, we have the visibility map page set
- * up in case we need to set this page's all_visible/all_frozen bit,
- * and we have a cleanup lock. Any tuples on this page are now sure
- * to be "counted" by this VACUUM.
- *
- * One last piece of preamble needs to take place before we can prune:
- * we need to consider new and empty pages.
- */
- vacrel->scanned_pages++;
- vacrel->tupcount_pages++;
-
- page = BufferGetPage(buf);
-
- if (PageIsNew(page))
+ /* Check for new or empty pages before lazy_scan_prune call */
+ if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, false, vmbuffer))
{
- /*
- * All-zeroes pages can be left over if either a backend extends
- * the relation by a single page, but crashes before the newly
- * initialized page has been written out, or when bulk-extending
- * the relation (which creates a number of empty pages at the tail
- * end of the relation, but enters them into the FSM).
- *
- * Note we do not enter the page into the visibilitymap. That has
- * the downside that we repeatedly visit this page in subsequent
- * vacuums, but otherwise we'll never not discover the space on a
- * promoted standby. The harm of repeated checking ought to
- * normally not be too bad - the space usually should be used at
- * some point, otherwise there wouldn't be any regular vacuums.
- *
- * Make sure these pages are in the FSM, to ensure they can be
- * reused. Do that by testing if there's any space recorded for
- * the page. If not, enter it. We do so after releasing the lock
- * on the heap page, the FSM is approximate, after all.
- */
- UnlockReleaseBuffer(buf);
-
- if (GetRecordedFreeSpace(vacrel->rel, blkno) == 0)
- {
- Size freespace = BLCKSZ - SizeOfPageHeaderData;
-
- RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
- }
- continue;
- }
-
- if (PageIsEmpty(page))
- {
- Size freespace = PageGetHeapFreeSpace(page);
-
- /*
- * Empty pages are always all-visible and all-frozen (note that
- * the same is currently not true for new pages, see above).
- */
- if (!PageIsAllVisible(page))
- {
- START_CRIT_SECTION();
-
- /* mark buffer dirty before writing a WAL record */
- MarkBufferDirty(buf);
-
- /*
- * It's possible that another backend has extended the heap,
- * initialized the page, and then failed to WAL-log the page
- * due to an ERROR. Since heap extension is not WAL-logged,
- * recovery might try to replay our record setting the page
- * all-visible and find that the page isn't initialized, which
- * will cause a PANIC. To prevent that, check whether the
- * page has been previously WAL-logged, and if not, do that
- * now.
- */
- if (RelationNeedsWAL(vacrel->rel) &&
- PageGetLSN(page) == InvalidXLogRecPtr)
- log_newpage_buffer(buf, true);
-
- PageSetAllVisible(page);
- visibilitymap_set(vacrel->rel, blkno, buf, InvalidXLogRecPtr,
- vmbuffer, InvalidTransactionId,
- VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
- END_CRIT_SECTION();
- }
-
- UnlockReleaseBuffer(buf);
- RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ /* Lock and pin released for us */
continue;
}
@@ -1564,7 +1470,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
/* now we can compute the new value for pg_class.reltuples */
vacrel->new_live_tuples = vac_estimate_reltuples(vacrel->rel, nblocks,
- vacrel->tupcount_pages,
+ vacrel->scanned_pages,
vacrel->live_tuples);
/*
@@ -1637,14 +1543,10 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
appendStringInfo(&buf,
_("%lld dead row versions cannot be removed yet, oldest xmin: %u\n"),
(long long) vacrel->new_dead_tuples, vacrel->OldestXmin);
- appendStringInfo(&buf, ngettext("Skipped %u page due to buffer pins, ",
- "Skipped %u pages due to buffer pins, ",
- vacrel->pinskipped_pages),
- vacrel->pinskipped_pages);
- appendStringInfo(&buf, ngettext("%u frozen page.\n",
- "%u frozen pages.\n",
- vacrel->frozenskipped_pages),
- vacrel->frozenskipped_pages);
+ appendStringInfo(&buf, ngettext("%u page skipped using visibility map.\n",
+ "%u pages skipped using visibility map.\n",
+ vacrel->rel_pages - vacrel->scanned_pages),
+ vacrel->rel_pages - vacrel->scanned_pages);
appendStringInfo(&buf, _("%s."), pg_rusage_show(&ru0));
ereport(elevel,
@@ -1658,6 +1560,132 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pfree(buf.data);
}
+/*
+ * lazy_scan_new_or_empty() -- lazy_scan_heap() new/empty page handling.
+ *
+ * Must call here to handle both new and empty pages before calling
+ * lazy_scan_prune or lazy_scan_noprune, since they're not prepared to deal
+ * with new or empty pages.
+ *
+ * It's necessary to consider new pages as a special case, since the rules for
+ * maintaining the visibility map and FSM with empty pages are a little
+ * different (though new pages can be truncated based on the usual rules).
+ *
+ * Empty pages are not really a special case -- they're just heap pages that
+ * have no allocated tuples (including even LP_UNUSED items). You might
+ * wonder why we need to handle them here all the same. It's only necessary
+ * because of a rare corner-case involving a hard crash during heap relation
+ * extension. If we ever make relation-extension crash safe, then it should
+ * no longer be necessary to deal with empty pages here (or new pages, for
+ * that matter).
+ *
+ * Caller can either hold a buffer cleanup lock on the buffer, or a simple
+ * shared lock.
+ */
+static bool
+lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf, BlockNumber blkno,
+ Page page, bool sharelock, Buffer vmbuffer)
+{
+ Size freespace;
+
+ if (PageIsNew(page))
+ {
+ /*
+ * All-zeroes pages can be left over if either a backend extends the
+ * relation by a single page, but crashes before the newly initialized
+ * page has been written out, or when bulk-extending the relation
+ * (which creates a number of empty pages at the tail end of the
+ * relation), and then enters them into the FSM.
+ *
+ * Note we do not enter the page into the visibilitymap. That has the
+ * downside that we repeatedly visit this page in subsequent vacuums,
+ * but otherwise we'll never not discover the space on a promoted
+ * standby. The harm of repeated checking ought to normally not be too
+ * bad - the space usually should be used at some point, otherwise
+ * there wouldn't be any regular vacuums.
+ *
+ * Make sure these pages are in the FSM, to ensure they can be reused.
+ * Do that by testing if there's any space recorded for the page. If
+ * not, enter it. We do so after releasing the lock on the heap page,
+ * the FSM is approximate, after all.
+ */
+ UnlockReleaseBuffer(buf);
+
+ if (GetRecordedFreeSpace(vacrel->rel, blkno) == 0)
+ {
+ freespace = BLCKSZ - SizeOfPageHeaderData;
+
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ }
+
+ return true;
+ }
+
+ if (PageIsEmpty(page))
+ {
+ /*
+ * It seems likely that caller will always be able to get a cleanup
+ * lock on an empty page. But don't take any chances -- escalate to
+ * an exclusive lock (still don't need a cleanup lock, though).
+ */
+ if (sharelock)
+ {
+ LockBuffer(buf, BUFFER_LOCK_UNLOCK);
+ LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
+
+ if (!PageIsEmpty(page))
+ {
+ /* page isn't new or empty -- keep lock and pin for now */
+ return false;
+ }
+ }
+ else
+ {
+ /* Already have a full cleanup lock (which is more than enough) */
+ }
+
+ freespace = PageGetHeapFreeSpace(page);
+
+ /*
+ * Unlike new pages, empty pages are always set all-visible and
+ * all-frozen.
+ */
+ if (!PageIsAllVisible(page))
+ {
+ START_CRIT_SECTION();
+
+ /* mark buffer dirty before writing a WAL record */
+ MarkBufferDirty(buf);
+
+ /*
+ * It's possible that another backend has extended the heap,
+ * initialized the page, and then failed to WAL-log the page due
+ * to an ERROR. Since heap extension is not WAL-logged, recovery
+ * might try to replay our record setting the page all-visible and
+ * find that the page isn't initialized, which will cause a PANIC.
+ * To prevent that, check whether the page has been previously
+ * WAL-logged, and if not, do that now.
+ */
+ if (RelationNeedsWAL(vacrel->rel) &&
+ PageGetLSN(page) == InvalidXLogRecPtr)
+ log_newpage_buffer(buf, true);
+
+ PageSetAllVisible(page);
+ visibilitymap_set(vacrel->rel, blkno, buf, InvalidXLogRecPtr,
+ vmbuffer, InvalidTransactionId,
+ VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
+ END_CRIT_SECTION();
+ }
+
+ UnlockReleaseBuffer(buf);
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ return true;
+ }
+
+ /* page isn't new or empty -- keep lock and pin */
+ return false;
+}
+
/*
* lazy_scan_prune() -- lazy_scan_heap() pruning and freezing.
*
@@ -1764,10 +1792,9 @@ retry:
* LP_DEAD items are processed outside of the loop.
*
* Note that we deliberately don't set hastup=true in the case of an
- * LP_DEAD item here, which is not how lazy_check_needs_freeze() or
- * count_nondeletable_pages() do it -- they only consider pages empty
- * when they only have LP_UNUSED items, which is important for
- * correctness.
+ * LP_DEAD item here, which is not how count_nondeletable_pages() does
+ * it -- it only considers pages empty/truncatable when they have no
+ * items at all (except LP_UNUSED items).
*
* Our assumption is that any LP_DEAD items we encounter here will
* become LP_UNUSED inside lazy_vacuum_heap_page() before we actually
@@ -2054,6 +2081,236 @@ retry:
vacrel->live_tuples += live_tuples;
}
+/*
+ * lazy_scan_noprune() -- lazy_scan_prune() variant without pruning
+ *
+ * Caller need only hold a pin and share lock on the buffer, unlike
+ * lazy_scan_prune, which requires a full cleanup lock.
+ *
+ * While pruning isn't performed here, we can at least collect existing
+ * LP_DEAD items into the dead_items array for removal from indexes. It's
+ * quite possible that earlier opportunistic pruning left LP_DEAD items
+ * behind, and we shouldn't miss out on an opportunity to make them reusable
+ * (VACUUM alone is capable of cleaning up line pointer bloat like this).
+ * Note that we'll only require an exclusive lock (not a cleanup lock) later
+ * on when we set these LP_DEAD items to LP_UNUSED in lazy_vacuum_heap_page.
+ *
+ * Freezing isn't performed here either. For aggressive VACUUM callers, we
+ * may return false to indicate that a full cleanup lock is required. This is
+ * necessary because pruning requires a cleanup lock, and because VACUUM
+ * cannot freeze a page's tuples until after pruning takes place (freezing
+ * tuples effectively requires a cleanup lock, though we don't need a cleanup
+ * lock in lazy_vacuum_heap_page or in lazy_scan_new_or_empty to set a heap
+ * page all-frozen in the visibility map).
+ *
+ * We'll always return true for a non-aggressive VACUUM, even when we know
+ * that this will cause them to miss out on freezing tuples from before
+ * vacrel->FreezeLimit cutoff -- they should never have to wait for a cleanup
+ * lock. This does mean that they definitely won't be able to advance
+ * relfrozenxid opportunistically (same applies to vacrel->MultiXactCutoff and
+ * relminmxid).
+ *
+ * See lazy_scan_prune for an explanation of hastup return flag.
+ */
+static bool
+lazy_scan_noprune(LVRelState *vacrel,
+ Buffer buf,
+ BlockNumber blkno,
+ Page page,
+ bool *hastup)
+{
+ OffsetNumber offnum,
+ maxoff;
+ bool has_tuple_needs_freeze = false;
+ int lpdead_items,
+ num_tuples,
+ live_tuples,
+ new_dead_tuples;
+ HeapTupleHeader tupleheader;
+ OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
+
+ *hastup = false; /* for now */
+
+ lpdead_items = 0;
+ num_tuples = 0;
+ live_tuples = 0;
+ new_dead_tuples = 0;
+
+ maxoff = PageGetMaxOffsetNumber(page);
+ for (offnum = FirstOffsetNumber;
+ offnum <= maxoff;
+ offnum = OffsetNumberNext(offnum))
+ {
+ ItemId itemid;
+ HeapTupleData tuple;
+
+ vacrel->offnum = offnum;
+ itemid = PageGetItemId(page, offnum);
+
+ if (!ItemIdIsUsed(itemid))
+ continue;
+
+ if (ItemIdIsRedirected(itemid))
+ {
+ *hastup = true; /* page won't be truncatable */
+ continue;
+ }
+
+ if (ItemIdIsDead(itemid))
+ {
+ /*
+ * Deliberately don't set hastup=true here. See same point in
+ * lazy_scan_prune for an explanation.
+ */
+ deadoffsets[lpdead_items++] = offnum;
+ continue;
+ }
+
+ tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
+ if (!has_tuple_needs_freeze &&
+ heap_tuple_needs_freeze(tupleheader, vacrel->FreezeLimit,
+ vacrel->MultiXactCutoff, buf))
+ {
+ if (vacrel->aggressive)
+ {
+ /* Going to have to get cleanup lock for lazy_scan_prune */
+ vacrel->offnum = InvalidOffsetNumber;
+ return false;
+ }
+
+ has_tuple_needs_freeze = true;
+ }
+
+ num_tuples++;
+ ItemPointerSet(&(tuple.t_self), blkno, offnum);
+ tuple.t_data = (HeapTupleHeader) PageGetItem(page, itemid);
+ tuple.t_len = ItemIdGetLength(itemid);
+ tuple.t_tableOid = RelationGetRelid(vacrel->rel);
+
+ switch (HeapTupleSatisfiesVacuum(&tuple, vacrel->OldestXmin, buf))
+ {
+ case HEAPTUPLE_DELETE_IN_PROGRESS:
+ case HEAPTUPLE_LIVE:
+
+ /*
+ * Count both cases as live, just like lazy_scan_prune
+ */
+ live_tuples++;
+
+ break;
+ case HEAPTUPLE_DEAD:
+ case HEAPTUPLE_RECENTLY_DEAD:
+
+ /*
+ * We count DEAD and RECENTLY_DEAD tuples in new_dead_tuples.
+ *
+ * lazy_scan_prune only does this for RECENTLY_DEAD tuples,
+ * and never has to deal with DEAD tuples directly (they
+ * reliably become LP_DEAD items through pruning). Our
+ * approach to DEAD tuples is a bit arbitrary, but it seems
+ * better than totally ignoring them.
+ */
+ new_dead_tuples++;
+ break;
+ case HEAPTUPLE_INSERT_IN_PROGRESS:
+
+ /*
+ * Do not count these rows as live, just like lazy_scan_prune
+ */
+ break;
+ default:
+ elog(ERROR, "unexpected HeapTupleSatisfiesVacuum result");
+ break;
+ }
+
+ }
+
+ vacrel->offnum = InvalidOffsetNumber;
+
+ if (has_tuple_needs_freeze)
+ {
+ /*
+ * Current non-aggressive VACUUM operation definitely won't be able to
+ * advance relfrozenxid or relminmxid
+ */
+ Assert(!vacrel->aggressive);
+ vacrel->freeze_cutoffs_valid = false;
+ }
+
+ /*
+ * Now save details of the LP_DEAD items from the page in the dead_items
+ * array iff VACUUM uses two-pass strategy case
+ */
+ if (vacrel->nindexes == 0)
+ {
+ /*
+ * We are not prepared to handle the corner case where a single pass
+ * strategy VACUUM cannot get a cleanup lock, and we then find LP_DEAD
+ * items. Repeat the same trick that we use for DEAD tuples: pretend
+ * that they're RECENTLY_DEAD tuples.
+ *
+ * There is no fundamental reason why we must take the easy way out
+ * like this. Finding a way to make these LP_DEAD items get set to
+ * LP_UNUSED would be less valuable and more complicated than it is in
+ * the two-pass strategy case, since it would necessitate that we
+ * repeat our lazy_scan_heap caller's page-at-a-time/one-pass-strategy
+ * heap vacuuming steps. Whereas in the two-pass strategy case,
+ * lazy_vacuum_heap_rel will set the LP_DEAD items to LP_UNUSED. It
+ * must always deal with things like remaining DEAD tuples with
+ * storage, new LP_DEAD items that we didn't see earlier on, etc.
+ */
+ if (lpdead_items > 0)
+ *hastup = true; /* page won't be truncatable */
+ num_tuples += lpdead_items;
+ new_dead_tuples += lpdead_items;
+ }
+ else if (lpdead_items > 0)
+ {
+ LVDeadItems *dead_items = vacrel->dead_items;
+ ItemPointerData tmp;
+
+ vacrel->lpdead_item_pages++;
+
+ ItemPointerSetBlockNumber(&tmp, blkno);
+
+ for (int i = 0; i < lpdead_items; i++)
+ {
+ ItemPointerSetOffsetNumber(&tmp, deadoffsets[i]);
+ dead_items->items[dead_items->num_items++] = tmp;
+ }
+
+ Assert(dead_items->num_items <= dead_items->max_items);
+ pgstat_progress_update_param(PROGRESS_VACUUM_NUM_DEAD_TUPLES,
+ dead_items->num_items);
+
+ vacrel->lpdead_items += lpdead_items;
+ }
+ else
+ {
+ /*
+ * We opt to skip FSM processing for the page on the grounds that it
+ * is probably being modified by concurrent DML operations. Seems
+ * best to assume that the space is best left behind for future
+ * updates of existing tuples. This matches what opportunistic
+ * pruning does.
+ *
+ * It's theoretically possible for us to set VM bits here too, but we
+ * don't try that either. It is highly unlikely to be possible, much
+ * less useful.
+ */
+ }
+
+ /*
+ * Finally, add relevant page-local counts to whole-VACUUM counts
+ */
+ vacrel->new_dead_tuples += new_dead_tuples;
+ vacrel->num_tuples += num_tuples;
+ vacrel->live_tuples += live_tuples;
+
+ /* Caller won't need to call lazy_scan_prune with same page */
+ return true;
+}
+
/*
* Remove the collected garbage tuples from the table and its indexes.
*
@@ -2500,67 +2757,6 @@ lazy_vacuum_heap_page(LVRelState *vacrel, BlockNumber blkno, Buffer buffer,
return index;
}
-/*
- * lazy_check_needs_freeze() -- scan page to see if any tuples
- * need to be cleaned to avoid wraparound
- *
- * Returns true if the page needs to be vacuumed using cleanup lock.
- * Also returns a flag indicating whether page contains any tuples at all.
- */
-static bool
-lazy_check_needs_freeze(Buffer buf, bool *hastup, LVRelState *vacrel)
-{
- Page page = BufferGetPage(buf);
- OffsetNumber offnum,
- maxoff;
- HeapTupleHeader tupleheader;
-
- *hastup = false;
-
- /*
- * New and empty pages, obviously, don't contain tuples. We could make
- * sure that the page is registered in the FSM, but it doesn't seem worth
- * waiting for a cleanup lock just for that, especially because it's
- * likely that the pin holder will do so.
- */
- if (PageIsNew(page) || PageIsEmpty(page))
- return false;
-
- maxoff = PageGetMaxOffsetNumber(page);
- for (offnum = FirstOffsetNumber;
- offnum <= maxoff;
- offnum = OffsetNumberNext(offnum))
- {
- ItemId itemid;
-
- /*
- * Set the offset number so that we can display it along with any
- * error that occurred while processing this tuple.
- */
- vacrel->offnum = offnum;
- itemid = PageGetItemId(page, offnum);
-
- /* this should match hastup test in count_nondeletable_pages() */
- if (ItemIdIsUsed(itemid))
- *hastup = true;
-
- /* dead and redirect items never need freezing */
- if (!ItemIdIsNormal(itemid))
- continue;
-
- tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
-
- if (heap_tuple_needs_freeze(tupleheader, vacrel->FreezeLimit,
- vacrel->MultiXactCutoff, buf))
- break;
- } /* scan along page */
-
- /* Clear the offset information once we have processed the given page. */
- vacrel->offnum = InvalidOffsetNumber;
-
- return (offnum <= maxoff);
-}
-
/*
* Trigger the failsafe to avoid wraparound failure when vacrel table has a
* relfrozenxid and/or relminmxid that is dangerously far in the past.
@@ -2655,7 +2851,7 @@ do_parallel_lazy_cleanup_all_indexes(LVRelState *vacrel)
*/
vacrel->lps->lvshared->reltuples = vacrel->new_rel_tuples;
vacrel->lps->lvshared->estimated_count =
- (vacrel->tupcount_pages < vacrel->rel_pages);
+ (vacrel->scanned_pages < vacrel->rel_pages);
/* Determine the number of parallel workers to launch */
if (vacrel->lps->lvshared->first_time)
@@ -2972,7 +3168,7 @@ lazy_cleanup_all_indexes(LVRelState *vacrel)
{
double reltuples = vacrel->new_rel_tuples;
bool estimated_count =
- vacrel->tupcount_pages < vacrel->rel_pages;
+ vacrel->scanned_pages < vacrel->rel_pages;
for (int idx = 0; idx < vacrel->nindexes; idx++)
{
@@ -3123,7 +3319,9 @@ lazy_cleanup_one_index(Relation indrel, IndexBulkDeleteResult *istat,
* should_attempt_truncation - should we attempt to truncate the heap?
*
* Don't even think about it unless we have a shot at releasing a goodly
- * number of pages. Otherwise, the time taken isn't worth it.
+ * number of pages. Otherwise, the time taken isn't worth it, mainly because
+ * an AccessExclusive lock must be replayed on any hot standby, where it can
+ * be particularly disruptive.
*
* Also don't attempt it if wraparound failsafe is in effect. It's hard to
* predict how long lazy_truncate_heap will take. Don't take any chances.
diff --git a/src/test/isolation/expected/vacuum-reltuples.out b/src/test/isolation/expected/vacuum-reltuples.out
index cdbe7f3a6..ce55376e7 100644
--- a/src/test/isolation/expected/vacuum-reltuples.out
+++ b/src/test/isolation/expected/vacuum-reltuples.out
@@ -45,7 +45,7 @@ step stats:
relpages|reltuples
--------+---------
- 1| 20
+ 1| 21
(1 row)
diff --git a/src/test/isolation/specs/vacuum-reltuples.spec b/src/test/isolation/specs/vacuum-reltuples.spec
index ae2f79b8f..a2a461f2f 100644
--- a/src/test/isolation/specs/vacuum-reltuples.spec
+++ b/src/test/isolation/specs/vacuum-reltuples.spec
@@ -2,9 +2,10 @@
# to page pins. We absolutely need to avoid setting reltuples=0 in
# such cases, since that interferes badly with planning.
#
-# Expected result in second permutation is 20 tuples rather than 21 as
-# for the others, because vacuum should leave the previous result
-# (from before the insert) in place.
+# Expected result for all three permutation is 21 tuples, including
+# the second permutation. VACUUM is able to count the concurrently
+# inserted tuple in its final reltuples, even when a cleanup lock
+# cannot be acquired on the affected heap page.
setup {
create table smalltbl
--
2.30.2
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-12-10 21:48 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2021-12-10 21:48 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Masahiko Sawada <[email protected]>
On Tue, Nov 30, 2021 at 11:52 AM Peter Geoghegan <[email protected]> wrote:
> I haven't had time to work through any of your feedback just yet --
> though it's certainly a priority for. I won't get to it until I return
> home from PGConf NYC next week.
Attached is v3, which works through most of your (Andres') feedback.
Changes in v3:
* While the first patch still gets rid of the "pinskipped_pages"
instrumentation, the second patch adds back a replacement that's
better targeted: it tracks and reports "missed_dead_tuples". This
means that log output will show the number of fully DEAD tuples with
storage that could not be pruned away due to the fact that that would
have required waiting for a cleanup lock. But we *don't* generally
report the number of pages that we couldn't get a cleanup lock on,
because that in itself doesn't mean that we skipped any useful work
(which is very much the point of all of the refactoring in the first
patch).
* We now have FSM processing in the lazy_scan_noprune case, which more
or less matches the standard lazy_scan_prune case.
* Many small tweaks, based on suggestions from Andres, and other
things that I noticed.
* Further simplification of the "consider skipping pages using
visibility map" logic -- now we always don't skip the last block in
the relation, without calling should_attempt_truncation() to make sure
we have a reason.
Note that this means that we'll always read the final page during
VACUUM, even when doing so is provably unhelpful. I'd prefer to keep
the code that deals with skipping pages using the visibility map as
simple as possible. There isn't much downside to always doing that
once my refactoring is in place: there is no risk that we'll wait for
a cleanup lock (on the final page in the rel) for no good reason.
We're only wasting one page access, at most.
(I'm not 100% sure that this is the right trade-off, actually, but
it's at least worth considering.)
Not included in v3:
* Still haven't added the isolation test for rel truncation, though
it's on my TODO list.
* I'm still working on the optimization that we discussed on this
thread: the optimization that allows the final relfrozenxid (that we
set in pg_class) to be determined dynamically, based on the actual
XIDs we observed in the table (we don't just naively use FreezeLimit).
I'm not ready to post that today, but it shouldn't take too much
longer to be good enough to review.
Thanks
--
Peter Geoghegan
Attachments:
[application/octet-stream] v3-0001-Simplify-lazy_scan_heap-s-handling-of-scanned-pag.patch (48.0K, ../../CAH2-Wz=c8LUnMuE1ioU=eLbfB4-7hNPu_yBpPyA1WRrHXLRaOQ@mail.gmail.com/2-v3-0001-Simplify-lazy_scan_heap-s-handling-of-scanned-pag.patch)
download | inline diff:
From e867662d06d8db72b7be4e26f509c57029d867f9 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Wed, 17 Nov 2021 21:27:06 -0800
Subject: [PATCH v3 1/2] Simplify lazy_scan_heap's handling of scanned pages.
Redefine a scanned page as any heap page that actually gets pinned by
VACUUM's first pass over the heap. Pages counted by scanned_pages are
now the complement of the pages that are skipped over using the
visibility map. This new definition significantly simplifies quite a
few things.
Now heap relation truncation, visibility map bit setting, tuple counting
(e.g., for pg_class.reltuples), and tuple freezing all share a common
definition of scanned_pages. That makes it possible to remove certain
special cases, that never made much sense. We no longer need to track
tupcount_pages separately (see bugfix commit 1914c5ea for details),
since we now always count tuples from pages that are scanned_pages. We
also don't need to needlessly distinguish between aggressive and
non-aggressive VACUUM operations when we cannot immediately acquire a
cleanup lock.
Since any VACUUM (not just an aggressive VACUUM) can sometimes advance
relfrozenxid, we now make non-aggressive VACUUMs work just a little
harder in order to make that desirable outcome more likely in practice.
Aggressive VACUUMs have long checked contended pages with only a shared
lock, to avoid needlessly waiting on a cleanup lock (in the common case
where the contended page has no tuples that need to be frozen anyway).
We still don't make non-aggressive VACUUMs wait for a cleanup lock, of
course -- if we did that they'd no longer be non-aggressive. But we now
make the non-aggressive case notice that a failure to acquire a cleanup
lock on one particular heap page does not in itself make it unsafe to
advance relfrozenxid for the whole relation (which is what we usually
see in the aggressive case already).
We now also collect LP_DEAD items in the dead_tuples array in the case
where we cannot immediately get a cleanup lock on the buffer. We cannot
prune without a cleanup lock, but opportunistic pruning may well have
left some LP_DEAD items behind in the past -- no reason to miss those.
Only VACUUM can mark these LP_DEAD items LP_UNUSED (no opportunistic
technique is independently capable of cleaning up line pointer bloat),
so we should not squander any opportunity to do that. Commit 8523492d4e
taught VACUUM to set LP_DEAD line pointers to LP_UNUSED while only
holding an exclusive lock (not a cleanup lock), so we can expect to set
existing LP_DEAD items to LP_UNUSED reliably, even when we cannot
acquire our own cleanup lock at either pass over the heap (unless we opt
to skip index vacuuming, which implies that there is no second pass over
the heap).
We no longer report on "pin skipped pages" in log output. A later patch
will add back an improved version of the same instrumentation. We don't
want to show any information about any failures to acquire cleanup locks
unless we actually failed to do useful work as a consequence. A page
that we could not acquire a cleanup lock on is now treated as equivalent
to any other scanned page in most cases.
---
src/backend/access/heap/vacuumlazy.c | 856 +++++++++++-------
.../isolation/expected/vacuum-reltuples.out | 2 +-
.../isolation/specs/vacuum-reltuples.spec | 7 +-
3 files changed, 541 insertions(+), 324 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 282b44f87..1fb8735a2 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -151,7 +151,7 @@ typedef enum
/*
* LVDeadItems stores TIDs whose index tuples are deleted by index vacuuming.
* Each TID points to an LP_DEAD line pointer from a heap page that has been
- * processed by lazy_scan_prune.
+ * processed by lazy_scan_prune (or by lazy_scan_noprune, perhaps).
*
* Also needed by lazy_vacuum_heap_rel, which marks the same LP_DEAD line
* pointers as LP_UNUSED during second heap pass.
@@ -284,6 +284,8 @@ typedef struct LVRelState
Relation *indrels;
int nindexes;
+ /* Aggressive VACUUM (scan all unfrozen pages)? */
+ bool aggressive;
/* Wraparound failsafe has been triggered? */
bool failsafe_active;
/* Consider index vacuuming bypass optimization? */
@@ -308,6 +310,8 @@ typedef struct LVRelState
/* VACUUM operation's cutoff for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
+ /* Are FreezeLimit/MultiXactCutoff still valid? */
+ bool freeze_cutoffs_valid;
/* Error reporting state */
char *relnamespace;
@@ -322,10 +326,8 @@ typedef struct LVRelState
*/
LVDeadItems *dead_items; /* TIDs whose index tuples we'll delete */
BlockNumber rel_pages; /* total number of pages */
- BlockNumber scanned_pages; /* number of pages we examined */
- BlockNumber pinskipped_pages; /* # of pages skipped due to a pin */
- BlockNumber frozenskipped_pages; /* # of frozen pages we skipped */
- BlockNumber tupcount_pages; /* pages whose tuples we counted */
+ BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
+ BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber pages_removed; /* pages remove by truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber nonempty_pages; /* actually, last nonempty page + 1 */
@@ -338,6 +340,7 @@ typedef struct LVRelState
/* Instrumentation counters */
int num_index_scans;
+ /* Counters that follow are only for scanned_pages */
int64 tuples_deleted; /* # deleted from table */
int64 lpdead_items; /* # deleted from indexes */
int64 new_dead_tuples; /* new estimated total # of dead items in
@@ -377,19 +380,22 @@ static int elevel = -1;
/* non-export function prototypes */
-static void lazy_scan_heap(LVRelState *vacrel, VacuumParams *params,
- bool aggressive);
+static void lazy_scan_heap(LVRelState *vacrel, VacuumParams *params);
+static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf,
+ BlockNumber blkno, Page page,
+ bool sharelock, Buffer vmbuffer);
static void lazy_scan_prune(LVRelState *vacrel, Buffer buf,
BlockNumber blkno, Page page,
GlobalVisState *vistest,
LVPagePruneState *prunestate);
+static bool lazy_scan_noprune(LVRelState *vacrel, Buffer buf,
+ BlockNumber blkno, Page page,
+ bool *hastup, bool *hasfreespace);
static void lazy_vacuum(LVRelState *vacrel);
static bool lazy_vacuum_all_indexes(LVRelState *vacrel);
static void lazy_vacuum_heap_rel(LVRelState *vacrel);
static int lazy_vacuum_heap_page(LVRelState *vacrel, BlockNumber blkno,
Buffer buffer, int index, Buffer *vmbuffer);
-static bool lazy_check_needs_freeze(Buffer buf, bool *hastup,
- LVRelState *vacrel);
static bool lazy_check_wraparound_failsafe(LVRelState *vacrel);
static void do_parallel_lazy_vacuum_all_indexes(LVRelState *vacrel);
static void do_parallel_lazy_cleanup_all_indexes(LVRelState *vacrel);
@@ -465,16 +471,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
int usecs;
double read_rate,
write_rate;
- bool aggressive; /* should we scan all unfrozen pages? */
- bool scanned_all_unfrozen; /* actually scanned all such pages? */
+ bool aggressive;
+ BlockNumber orig_rel_pages;
char **indnames = NULL;
TransactionId xidFullScanLimit;
MultiXactId mxactFullScanLimit;
BlockNumber new_rel_pages;
BlockNumber new_rel_allvisible;
double new_live_tuples;
- TransactionId new_frozen_xid;
- MultiXactId new_min_multi;
ErrorContextCallback errcallback;
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
@@ -529,6 +533,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->rel = rel;
vac_open_indexes(vacrel->rel, RowExclusiveLock, &vacrel->nindexes,
&vacrel->indrels);
+ vacrel->aggressive = aggressive;
vacrel->failsafe_active = false;
vacrel->consider_bypass_optimization = true;
@@ -573,6 +578,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->OldestXmin = OldestXmin;
vacrel->FreezeLimit = FreezeLimit;
vacrel->MultiXactCutoff = MultiXactCutoff;
+ /* Track if cutoffs became invalid (possible in !aggressive case only) */
+ vacrel->freeze_cutoffs_valid = true;
vacrel->relnamespace = get_namespace_name(RelationGetNamespace(rel));
vacrel->relname = pstrdup(RelationGetRelationName(rel));
@@ -609,30 +616,16 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* Call lazy_scan_heap to perform all required heap pruning, index
* vacuuming, and heap vacuuming (plus related processing)
*/
- lazy_scan_heap(vacrel, params, aggressive);
+ lazy_scan_heap(vacrel, params);
/* Done with indexes */
vac_close_indexes(vacrel->nindexes, vacrel->indrels, NoLock);
/*
- * Compute whether we actually scanned the all unfrozen pages. If we did,
- * we can adjust relfrozenxid and relminmxid.
- *
- * NB: We need to check this before truncating the relation, because that
- * will change ->rel_pages.
- */
- if ((vacrel->scanned_pages + vacrel->frozenskipped_pages)
- < vacrel->rel_pages)
- {
- Assert(!aggressive);
- scanned_all_unfrozen = false;
- }
- else
- scanned_all_unfrozen = true;
-
- /*
- * Optionally truncate the relation.
+ * Optionally truncate the relation. But remember the relation size used
+ * by lazy_scan_prune for later first.
*/
+ orig_rel_pages = vacrel->rel_pages;
if (should_attempt_truncation(vacrel))
{
/*
@@ -663,28 +656,44 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
*
* For safety, clamp relallvisible to be not more than what we're setting
* relpages to.
- *
- * Also, don't change relfrozenxid/relminmxid if we skipped any pages,
- * since then we don't know for certain that all tuples have a newer xmin.
*/
- new_rel_pages = vacrel->rel_pages;
+ new_rel_pages = vacrel->rel_pages; /* After possible rel truncation */
new_live_tuples = vacrel->new_live_tuples;
visibilitymap_count(rel, &new_rel_allvisible, NULL);
if (new_rel_allvisible > new_rel_pages)
new_rel_allvisible = new_rel_pages;
- new_frozen_xid = scanned_all_unfrozen ? FreezeLimit : InvalidTransactionId;
- new_min_multi = scanned_all_unfrozen ? MultiXactCutoff : InvalidMultiXactId;
-
- vac_update_relstats(rel,
- new_rel_pages,
- new_live_tuples,
- new_rel_allvisible,
- vacrel->nindexes > 0,
- new_frozen_xid,
- new_min_multi,
- false);
+ /*
+ * Aggressive VACUUM must reliably advance relfrozenxid (and relminmxid).
+ * We are able to advance relfrozenxid in a non-aggressive VACUUM too,
+ * provided we didn't skip any all-visible (not all-frozen) pages using
+ * the visibility map, and assuming that we didn't fail to get a cleanup
+ * lock that made it unsafe with respect to FreezeLimit (or perhaps our
+ * MultiXactCutoff) established for VACUUM operation.
+ *
+ * NB: We must use orig_rel_pages, not vacrel->rel_pages, since we want
+ * the rel_pages used by lazy_scan_heap, which won't match when we
+ * happened to truncate the relation afterwards.
+ */
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
+ !vacrel->freeze_cutoffs_valid)
+ {
+ /* Cannot advance relfrozenxid/relminmxid -- just update pg_class */
+ Assert(!aggressive);
+ vac_update_relstats(rel, new_rel_pages, new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ InvalidTransactionId, InvalidMultiXactId, false);
+ }
+ else
+ {
+ /* Can safely advance relfrozen and relminmxid, too */
+ Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
+ orig_rel_pages);
+ vac_update_relstats(rel, new_rel_pages, new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ FreezeLimit, MultiXactCutoff, false);
+ }
/*
* Report results to the stats collector, too.
@@ -713,7 +722,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
StringInfoData buf;
char *msgfmt;
- BlockNumber orig_rel_pages;
TimestampDifference(starttime, endtime, &secs, &usecs);
@@ -760,10 +768,9 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->relnamespace,
vacrel->relname,
vacrel->num_index_scans);
- appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped due to pins, %u skipped frozen\n"),
+ appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped frozen\n"),
vacrel->pages_removed,
vacrel->rel_pages,
- vacrel->pinskipped_pages,
vacrel->frozenskipped_pages);
appendStringInfo(&buf,
_("tuples: %lld removed, %lld remain, %lld are dead but not yet removable, oldest xmin: %u\n"),
@@ -771,7 +778,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
(long long) vacrel->new_rel_tuples,
(long long) vacrel->new_dead_tuples,
OldestXmin);
- orig_rel_pages = vacrel->rel_pages + vacrel->pages_removed;
if (orig_rel_pages > 0)
{
if (vacrel->do_index_vacuuming)
@@ -888,7 +894,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* supply.
*/
static void
-lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
+lazy_scan_heap(LVRelState *vacrel, VacuumParams *params)
{
LVDeadItems *dead_items;
BlockNumber nblocks,
@@ -910,7 +916,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pg_rusage_init(&ru0);
- if (aggressive)
+ if (vacrel->aggressive)
ereport(elevel,
(errmsg("aggressively vacuuming \"%s.%s\"",
vacrel->relnamespace,
@@ -922,14 +928,11 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
vacrel->relname)));
nblocks = RelationGetNumberOfBlocks(vacrel->rel);
- next_unskippable_block = 0;
next_failsafe_block = 0;
next_fsm_block_to_vacuum = 0;
vacrel->rel_pages = nblocks;
vacrel->scanned_pages = 0;
- vacrel->pinskipped_pages = 0;
vacrel->frozenskipped_pages = 0;
- vacrel->tupcount_pages = 0;
vacrel->pages_removed = 0;
vacrel->lpdead_item_pages = 0;
vacrel->nonempty_pages = 0;
@@ -969,7 +972,9 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pgstat_progress_update_multi_param(3, initprog_index, initprog_val);
/*
- * Except when aggressive is set, we want to skip pages that are
+ * Set things up for skipping blocks using visibility map.
+ *
+ * Except when vacrel->aggressive is set, we want to skip pages that are
* all-visible according to the visibility map, but only when we can skip
* at least SKIP_PAGES_THRESHOLD consecutive pages. Since we're reading
* sequentially, the OS should be doing readahead for us, so there's no
@@ -978,8 +983,8 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* page means that we can't update relfrozenxid, so we only want to do it
* if we can skip a goodly number of pages.
*
- * When aggressive is set, we can't skip pages just because they are
- * all-visible, but we can still skip pages that are all-frozen, since
+ * When vacrel->aggressive is set, we can't skip pages just because they
+ * are all-visible, but we can still skip pages that are all-frozen, since
* such pages do not need freezing and do not affect the value that we can
* safely set for relfrozenxid or relminmxid.
*
@@ -1002,18 +1007,11 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* just added to that page are necessarily newer than the GlobalXmin we
* computed, so they'll have no effect on the value to which we can safely
* set relfrozenxid. A similar argument applies for MXIDs and relminmxid.
- *
- * We will scan the table's last page, at least to the extent of
- * determining whether it has tuples or not, even if it should be skipped
- * according to the above rules; except when we've already determined that
- * it's not worth trying to truncate the table. This avoids having
- * lazy_truncate_heap() take access-exclusive lock on the table to attempt
- * a truncation that just fails immediately because there are tuples in
- * the last page. This is worth avoiding mainly because such a lock must
- * be replayed on any hot standby, where it can be disruptive.
*/
+ skipping_blocks = false;
if ((params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0)
{
+ next_unskippable_block = 0;
while (next_unskippable_block < nblocks)
{
uint8 vmstatus;
@@ -1021,7 +1019,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
vmstatus = visibilitymap_get_status(vacrel->rel,
next_unskippable_block,
&vmbuffer);
- if (aggressive)
+ if (vacrel->aggressive)
{
if ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0)
break;
@@ -1034,12 +1032,11 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
vacuum_delay_point();
next_unskippable_block++;
}
+ if (next_unskippable_block >= SKIP_PAGES_THRESHOLD)
+ skipping_blocks = true;
}
-
- if (next_unskippable_block >= SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
else
- skipping_blocks = false;
+ next_unskippable_block = InvalidBlockNumber;
for (blkno = 0; blkno < nblocks; blkno++)
{
@@ -1048,44 +1045,38 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
bool all_visible_according_to_vm = false;
LVPagePruneState prunestate;
- /*
- * Consider need to skip blocks. See note above about forcing
- * scanning of last page.
- */
-#define FORCE_CHECK_PAGE() \
- (blkno == nblocks - 1 && should_attempt_truncation(vacrel))
-
pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
blkno, InvalidOffsetNumber);
+ /*
+ * Consider need to skip blocks using visibility map
+ */
if (blkno == next_unskippable_block)
{
/* Time to advance next_unskippable_block */
+ Assert((params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0);
next_unskippable_block++;
- if ((params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0)
+ while (next_unskippable_block < nblocks)
{
- while (next_unskippable_block < nblocks)
- {
- uint8 vmskipflags;
+ uint8 vmskipflags;
- vmskipflags = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (aggressive)
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
+ vmskipflags = visibilitymap_get_status(vacrel->rel,
+ next_unskippable_block,
+ &vmbuffer);
+ if (vacrel->aggressive)
+ {
+ if ((vmskipflags & VISIBILITYMAP_ALL_FROZEN) == 0)
+ break;
}
+ else
+ {
+ if ((vmskipflags & VISIBILITYMAP_ALL_VISIBLE) == 0)
+ break;
+ }
+ vacuum_delay_point();
+ next_unskippable_block++;
}
/*
@@ -1102,19 +1093,24 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* it's not all-visible. But in an aggressive vacuum we know only
* that it's not all-frozen, so it might still be all-visible.
*/
- if (aggressive && VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
+ if (vacrel->aggressive &&
+ VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
all_visible_according_to_vm = true;
}
else
{
/*
- * The current block is potentially skippable; if we've seen a
- * long enough run of skippable blocks to justify skipping it, and
- * we're not forced to check it, then go ahead and skip.
- * Otherwise, the page must be at least all-visible if not
- * all-frozen, so we can set all_visible_according_to_vm = true.
+ * The current page can be skipped if we've seen a long enough run
+ * of skippable blocks to justify skipping it -- provided it's not
+ * the last page in the relation (according to rel_pages/nblocks).
+ *
+ * We always scan the table's last page to determine whether it
+ * has tuples or not, even if it would otherwise be skipped. This
+ * avoids having lazy_truncate_heap() take access-exclusive lock
+ * on the table to attempt a truncation that just fails
+ * immediately because there are tuples on the last page.
*/
- if (skipping_blocks && !FORCE_CHECK_PAGE())
+ if (skipping_blocks && blkno < nblocks - 1)
{
/*
* Tricky, tricky. If this is in aggressive vacuum, the page
@@ -1123,18 +1119,31 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* careful to count it as a skipped all-frozen page in that
* case, or else we'll think we can't update relfrozenxid and
* relminmxid. If it's not an aggressive vacuum, we don't
- * know whether it was all-frozen, so we have to recheck; but
- * in this case an approximate answer is OK.
+ * know whether it was initially all-frozen, so we have to
+ * recheck.
*/
- if (aggressive || VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
+ if (vacrel->aggressive ||
+ VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
vacrel->frozenskipped_pages++;
continue;
}
+
+ /*
+ * Otherwise we scan the page. It must be at least all-visible,
+ * if not all-frozen.
+ */
all_visible_according_to_vm = true;
}
vacuum_delay_point();
+ /*
+ * We're not skipping this page using the visibility map, and so it is
+ * (by definition) a scanned page. Any tuples from this page are now
+ * guaranteed to be counted below, after some preparatory checks.
+ */
+ vacrel->scanned_pages++;
+
/*
* Regularly check if wraparound failsafe should trigger.
*
@@ -1189,174 +1198,78 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
}
/*
- * Set up visibility map page as needed.
- *
* Pin the visibility map page in case we need to mark the page
* all-visible. In most cases this will be very cheap, because we'll
- * already have the correct page pinned anyway. However, it's
- * possible that (a) next_unskippable_block is covered by a different
- * VM page than the current block or (b) we released our pin and did a
- * cycle of index vacuuming.
+ * already have the correct page pinned anyway.
*/
visibilitymap_pin(vacrel->rel, blkno, &vmbuffer);
+ /* Finished preparatory checks. Actually scan the page. */
buf = ReadBufferExtended(vacrel->rel, MAIN_FORKNUM, blkno,
RBM_NORMAL, vacrel->bstrategy);
+ page = BufferGetPage(buf);
/*
- * We need buffer cleanup lock so that we can prune HOT chains and
- * defragment the page.
+ * We need a buffer cleanup lock to prune HOT chains and defragment
+ * the page in lazy_scan_prune. But when it's not possible to acquire
+ * a cleanup lock right away, we may be able to settle for reduced
+ * processing using lazy_scan_noprune.
*/
if (!ConditionalLockBufferForCleanup(buf))
{
- bool hastup;
+ bool hastup,
+ hasfreespace;
- /*
- * If we're not performing an aggressive scan to guard against XID
- * wraparound, and we don't want to forcibly check the page, then
- * it's OK to skip vacuuming pages we get a lock conflict on. They
- * will be dealt with in some future vacuum.
- */
- if (!aggressive && !FORCE_CHECK_PAGE())
- {
- ReleaseBuffer(buf);
- vacrel->pinskipped_pages++;
- continue;
- }
-
- /*
- * Read the page with share lock to see if any xids on it need to
- * be frozen. If not we just skip the page, after updating our
- * scan statistics. If there are some, we wait for cleanup lock.
- *
- * We could defer the lock request further by remembering the page
- * and coming back to it later, or we could even register
- * ourselves for multiple buffers and then service whichever one
- * is received first. For now, this seems good enough.
- *
- * If we get here with aggressive false, then we're just forcibly
- * checking the page, and so we don't want to insist on getting
- * the lock; we only need to know if the page contains tuples, so
- * that we can update nonempty_pages correctly. It's convenient
- * to use lazy_check_needs_freeze() for both situations, though.
- */
LockBuffer(buf, BUFFER_LOCK_SHARE);
- if (!lazy_check_needs_freeze(buf, &hastup, vacrel))
+
+ /* Check for new or empty pages before lazy_scan_noprune call */
+ if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, true,
+ vmbuffer))
{
- UnlockReleaseBuffer(buf);
- vacrel->scanned_pages++;
- vacrel->pinskipped_pages++;
- if (hastup)
- vacrel->nonempty_pages = blkno + 1;
+ /* Processed as new/empty page (lock and pin released) */
continue;
}
- if (!aggressive)
+
+ /* Collect LP_DEAD items in dead_items array, count tuples */
+ if (lazy_scan_noprune(vacrel, buf, blkno, page, &hastup,
+ &hasfreespace))
{
+ Size freespace;
+
/*
- * Here, we must not advance scanned_pages; that would amount
- * to claiming that the page contains no freezable tuples.
+ * Processed page successfully (without cleanup lock) -- just
+ * need to perform rel truncation and FSM steps, much like the
+ * lazy_scan_prune case. Don't bother trying to match its
+ * visibility map setting steps, though.
*/
- UnlockReleaseBuffer(buf);
- vacrel->pinskipped_pages++;
if (hastup)
vacrel->nonempty_pages = blkno + 1;
+ if (hasfreespace)
+ freespace = PageGetHeapFreeSpace(page);
+ UnlockReleaseBuffer(buf);
+ if (hasfreespace)
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
continue;
}
+
+ /*
+ * lazy_scan_noprune could not do all required processing. Wait
+ * for a cleanup lock, and call lazy_scan_prune in the usual way.
+ */
+ Assert(vacrel->aggressive);
LockBuffer(buf, BUFFER_LOCK_UNLOCK);
LockBufferForCleanup(buf);
- /* drop through to normal processing */
}
- /*
- * By here we definitely have enough dead_items space for whatever
- * LP_DEAD tids are on this page, we have the visibility map page set
- * up in case we need to set this page's all_visible/all_frozen bit,
- * and we have a cleanup lock. Any tuples on this page are now sure
- * to be "counted" by this VACUUM.
- *
- * One last piece of preamble needs to take place before we can prune:
- * we need to consider new and empty pages.
- */
- vacrel->scanned_pages++;
- vacrel->tupcount_pages++;
-
- page = BufferGetPage(buf);
-
- if (PageIsNew(page))
+ /* Check for new or empty pages before lazy_scan_prune call */
+ if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, false, vmbuffer))
{
- /*
- * All-zeroes pages can be left over if either a backend extends
- * the relation by a single page, but crashes before the newly
- * initialized page has been written out, or when bulk-extending
- * the relation (which creates a number of empty pages at the tail
- * end of the relation, but enters them into the FSM).
- *
- * Note we do not enter the page into the visibilitymap. That has
- * the downside that we repeatedly visit this page in subsequent
- * vacuums, but otherwise we'll never not discover the space on a
- * promoted standby. The harm of repeated checking ought to
- * normally not be too bad - the space usually should be used at
- * some point, otherwise there wouldn't be any regular vacuums.
- *
- * Make sure these pages are in the FSM, to ensure they can be
- * reused. Do that by testing if there's any space recorded for
- * the page. If not, enter it. We do so after releasing the lock
- * on the heap page, the FSM is approximate, after all.
- */
- UnlockReleaseBuffer(buf);
-
- if (GetRecordedFreeSpace(vacrel->rel, blkno) == 0)
- {
- Size freespace = BLCKSZ - SizeOfPageHeaderData;
-
- RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
- }
- continue;
- }
-
- if (PageIsEmpty(page))
- {
- Size freespace = PageGetHeapFreeSpace(page);
-
- /*
- * Empty pages are always all-visible and all-frozen (note that
- * the same is currently not true for new pages, see above).
- */
- if (!PageIsAllVisible(page))
- {
- START_CRIT_SECTION();
-
- /* mark buffer dirty before writing a WAL record */
- MarkBufferDirty(buf);
-
- /*
- * It's possible that another backend has extended the heap,
- * initialized the page, and then failed to WAL-log the page
- * due to an ERROR. Since heap extension is not WAL-logged,
- * recovery might try to replay our record setting the page
- * all-visible and find that the page isn't initialized, which
- * will cause a PANIC. To prevent that, check whether the
- * page has been previously WAL-logged, and if not, do that
- * now.
- */
- if (RelationNeedsWAL(vacrel->rel) &&
- PageGetLSN(page) == InvalidXLogRecPtr)
- log_newpage_buffer(buf, true);
-
- PageSetAllVisible(page);
- visibilitymap_set(vacrel->rel, blkno, buf, InvalidXLogRecPtr,
- vmbuffer, InvalidTransactionId,
- VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
- END_CRIT_SECTION();
- }
-
- UnlockReleaseBuffer(buf);
- RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ /* Processed as new/empty page (lock and pin released) */
continue;
}
/*
- * Prune and freeze tuples.
+ * Prune, freeze, and count tuples.
*
* Accumulates details of remaining LP_DEAD line pointers on page in
* dead_items array. This includes LP_DEAD line pointers that we
@@ -1564,7 +1477,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
/* now we can compute the new value for pg_class.reltuples */
vacrel->new_live_tuples = vac_estimate_reltuples(vacrel->rel, nblocks,
- vacrel->tupcount_pages,
+ vacrel->scanned_pages,
vacrel->live_tuples);
/*
@@ -1637,14 +1550,6 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
appendStringInfo(&buf,
_("%lld dead row versions cannot be removed yet, oldest xmin: %u\n"),
(long long) vacrel->new_dead_tuples, vacrel->OldestXmin);
- appendStringInfo(&buf, ngettext("Skipped %u page due to buffer pins, ",
- "Skipped %u pages due to buffer pins, ",
- vacrel->pinskipped_pages),
- vacrel->pinskipped_pages);
- appendStringInfo(&buf, ngettext("%u frozen page.\n",
- "%u frozen pages.\n",
- vacrel->frozenskipped_pages),
- vacrel->frozenskipped_pages);
appendStringInfo(&buf, _("%s."), pg_rusage_show(&ru0));
ereport(elevel,
@@ -1658,6 +1563,138 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pfree(buf.data);
}
+/*
+ * lazy_scan_new_or_empty() -- lazy_scan_heap() new/empty page handling.
+ *
+ * Must call here to handle both new and empty pages before calling
+ * lazy_scan_prune or lazy_scan_noprune, since they're not prepared to deal
+ * with new or empty pages.
+ *
+ * It's necessary to consider new pages as a special case, since the rules for
+ * maintaining the visibility map and FSM with empty pages are a little
+ * different (though new pages can be truncated based on the usual rules).
+ *
+ * Empty pages are not really a special case -- they're just heap pages that
+ * have no allocated tuples (including even LP_UNUSED items). You might
+ * wonder why we need to handle them here all the same. It's only necessary
+ * because of a corner-case involving a hard crash during heap relation
+ * extension. If we ever make relation-extension crash safe, then it should
+ * no longer be necessary to deal with empty pages here (or new pages, for
+ * that matter).
+ *
+ * Caller must hold at least a shared lock. We might need to escalate the
+ * lock in that case, so the type of lock caller holds needs to be specified
+ * using 'sharelock' argument.
+ *
+ * Returns false in common case where caller should go on to call
+ * lazy_scan_prune (or lazy_scan_noprune). Otherwise returns true, indicating
+ * that lazy_scan_heap is done processing the page, releasing lock on caller's
+ * behalf.
+ */
+static bool
+lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf, BlockNumber blkno,
+ Page page, bool sharelock, Buffer vmbuffer)
+{
+ Size freespace;
+
+ if (PageIsNew(page))
+ {
+ /*
+ * All-zeroes pages can be left over if either a backend extends the
+ * relation by a single page, but crashes before the newly initialized
+ * page has been written out, or when bulk-extending the relation
+ * (which creates a number of empty pages at the tail end of the
+ * relation), and then enters them into the FSM.
+ *
+ * Note we do not enter the page into the visibilitymap. That has the
+ * downside that we repeatedly visit this page in subsequent vacuums,
+ * but otherwise we'll never discover the space on a promoted standby.
+ * The harm of repeated checking ought to normally not be too bad.
+ * The space usually should be used at some point, otherwise there
+ * wouldn't be any regular vacuums.
+ *
+ * Make sure these pages are in the FSM, to ensure they can be reused.
+ * Do that by testing if there's any space recorded for the page. If
+ * not, enter it. We do so after releasing the lock on the heap page,
+ * the FSM is approximate, after all.
+ */
+ UnlockReleaseBuffer(buf);
+
+ if (GetRecordedFreeSpace(vacrel->rel, blkno) == 0)
+ {
+ freespace = BLCKSZ - SizeOfPageHeaderData;
+
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ }
+
+ return true;
+ }
+
+ if (PageIsEmpty(page))
+ {
+ /*
+ * It seems likely that caller will always be able to get a cleanup
+ * lock on an empty page. But don't take any chances -- escalate to
+ * an exclusive lock (still don't need a cleanup lock, though).
+ */
+ if (sharelock)
+ {
+ LockBuffer(buf, BUFFER_LOCK_UNLOCK);
+ LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
+
+ if (!PageIsEmpty(page))
+ {
+ /* page isn't new or empty -- keep lock and pin for now */
+ return false;
+ }
+ }
+ else
+ {
+ /* Already have a full cleanup lock (which is more than enough) */
+ }
+
+ freespace = PageGetHeapFreeSpace(page);
+
+ /*
+ * Unlike new pages, empty pages are always set all-visible and
+ * all-frozen.
+ */
+ if (!PageIsAllVisible(page))
+ {
+ START_CRIT_SECTION();
+
+ /* mark buffer dirty before writing a WAL record */
+ MarkBufferDirty(buf);
+
+ /*
+ * It's possible that another backend has extended the heap,
+ * initialized the page, and then failed to WAL-log the page due
+ * to an ERROR. Since heap extension is not WAL-logged, recovery
+ * might try to replay our record setting the page all-visible and
+ * find that the page isn't initialized, which will cause a PANIC.
+ * To prevent that, check whether the page has been previously
+ * WAL-logged, and if not, do that now.
+ */
+ if (RelationNeedsWAL(vacrel->rel) &&
+ PageGetLSN(page) == InvalidXLogRecPtr)
+ log_newpage_buffer(buf, true);
+
+ PageSetAllVisible(page);
+ visibilitymap_set(vacrel->rel, blkno, buf, InvalidXLogRecPtr,
+ vmbuffer, InvalidTransactionId,
+ VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
+ END_CRIT_SECTION();
+ }
+
+ UnlockReleaseBuffer(buf);
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ return true;
+ }
+
+ /* page isn't new or empty -- keep lock and pin */
+ return false;
+}
+
/*
* lazy_scan_prune() -- lazy_scan_heap() pruning and freezing.
*
@@ -1702,6 +1739,8 @@ lazy_scan_prune(LVRelState *vacrel,
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
+ Assert(BufferGetBlockNumber(buf) == blkno);
+
maxoff = PageGetMaxOffsetNumber(page);
retry:
@@ -1764,10 +1803,9 @@ retry:
* LP_DEAD items are processed outside of the loop.
*
* Note that we deliberately don't set hastup=true in the case of an
- * LP_DEAD item here, which is not how lazy_check_needs_freeze() or
- * count_nondeletable_pages() do it -- they only consider pages empty
- * when they only have LP_UNUSED items, which is important for
- * correctness.
+ * LP_DEAD item here, which is not how count_nondeletable_pages() does
+ * it -- it only considers pages empty/truncatable when they have no
+ * items at all (except LP_UNUSED items).
*
* Our assumption is that any LP_DEAD items we encounter here will
* become LP_UNUSED inside lazy_vacuum_heap_page() before we actually
@@ -2054,6 +2092,243 @@ retry:
vacrel->live_tuples += live_tuples;
}
+/*
+ * lazy_scan_noprune() -- lazy_scan_prune() variant without pruning
+ *
+ * Caller need only hold a pin and share lock on the buffer, unlike
+ * lazy_scan_prune, which requires a full cleanup lock.
+ *
+ * While pruning isn't performed here, we can at least collect existing
+ * LP_DEAD items into the dead_items array for removal from indexes. It's
+ * quite possible that earlier opportunistic pruning left LP_DEAD items
+ * behind, and we shouldn't miss out on an opportunity to make them reusable
+ * (VACUUM alone is capable of cleaning up line pointer bloat like this).
+ * Note that we'll only require an exclusive lock (not a cleanup lock) later
+ * on when we set these LP_DEAD items to LP_UNUSED in lazy_vacuum_heap_page.
+ *
+ * Freezing isn't performed here either. For aggressive VACUUM callers, we
+ * may return false to indicate that a full cleanup lock is required. This is
+ * necessary because pruning requires a cleanup lock, and because VACUUM
+ * cannot freeze a page's tuples until after pruning takes place (freezing
+ * tuples effectively requires a cleanup lock, though we don't need a cleanup
+ * lock in lazy_vacuum_heap_page or in lazy_scan_new_or_empty to set a heap
+ * page all-frozen in the visibility map).
+ *
+ * Returns true to indicate that all required processing has been performed.
+ * We'll always return true for a non-aggressive VACUUM, even when we know
+ * that this will cause them to miss out on freezing tuples from before
+ * vacrel->FreezeLimit cutoff -- they should never have to wait for a cleanup
+ * lock. This does mean that they definitely won't be able to advance
+ * relfrozenxid opportunistically (same applies to vacrel->MultiXactCutoff and
+ * relminmxid). Caller waits for full cleanup lock when we return false.
+ *
+ * See lazy_scan_prune for an explanation of hastup return flag. The
+ * hasfreespace flag instructs caller on whether or not it should do generic
+ * FSM processing for page, which is determined based on almost the same
+ * criteria as the lazy_scan_prune case.
+ */
+static bool
+lazy_scan_noprune(LVRelState *vacrel,
+ Buffer buf,
+ BlockNumber blkno,
+ Page page,
+ bool *hastup,
+ bool *hasfreespace)
+{
+ OffsetNumber offnum,
+ maxoff;
+ bool has_tuple_needs_freeze = false;
+ int lpdead_items,
+ num_tuples,
+ live_tuples,
+ new_dead_tuples;
+ HeapTupleHeader tupleheader;
+ OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
+
+ Assert(BufferGetBlockNumber(buf) == blkno);
+
+ *hastup = false; /* for now */
+ *hasfreespace = false; /* for now */
+
+ lpdead_items = 0;
+ num_tuples = 0;
+ live_tuples = 0;
+ new_dead_tuples = 0;
+
+ maxoff = PageGetMaxOffsetNumber(page);
+ for (offnum = FirstOffsetNumber;
+ offnum <= maxoff;
+ offnum = OffsetNumberNext(offnum))
+ {
+ ItemId itemid;
+ HeapTupleData tuple;
+
+ vacrel->offnum = offnum;
+ itemid = PageGetItemId(page, offnum);
+
+ if (!ItemIdIsUsed(itemid))
+ continue;
+
+ if (ItemIdIsRedirected(itemid))
+ {
+ *hastup = true; /* page prevents rel truncation */
+ continue;
+ }
+
+ if (ItemIdIsDead(itemid))
+ {
+ /*
+ * Deliberately don't set hastup=true here. See same point in
+ * lazy_scan_prune for an explanation.
+ */
+ deadoffsets[lpdead_items++] = offnum;
+ continue;
+ }
+
+ tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
+ if (!has_tuple_needs_freeze &&
+ heap_tuple_needs_freeze(tupleheader, vacrel->FreezeLimit,
+ vacrel->MultiXactCutoff, buf))
+ {
+ if (vacrel->aggressive)
+ {
+ /* Going to have to get cleanup lock for lazy_scan_prune */
+ vacrel->offnum = InvalidOffsetNumber;
+ return false;
+ }
+
+ has_tuple_needs_freeze = true;
+ }
+
+ num_tuples++;
+ ItemPointerSet(&(tuple.t_self), blkno, offnum);
+ tuple.t_data = (HeapTupleHeader) PageGetItem(page, itemid);
+ tuple.t_len = ItemIdGetLength(itemid);
+ tuple.t_tableOid = RelationGetRelid(vacrel->rel);
+
+ switch (HeapTupleSatisfiesVacuum(&tuple, vacrel->OldestXmin, buf))
+ {
+ case HEAPTUPLE_DELETE_IN_PROGRESS:
+ case HEAPTUPLE_LIVE:
+
+ /*
+ * Count both cases as live, just like lazy_scan_prune
+ */
+ live_tuples++;
+
+ break;
+ case HEAPTUPLE_DEAD:
+
+ /*
+ * There is some useful work for pruning to do, that won't be
+ * done due to failure to get a cleanup lock.
+ *
+ * TODO Add dedicated instrumentation for this case
+ */
+ break;
+ case HEAPTUPLE_RECENTLY_DEAD:
+
+ /*
+ * Count in new_dead_tuples, just like lazy_scan_prune
+ */
+ new_dead_tuples++;
+ break;
+ case HEAPTUPLE_INSERT_IN_PROGRESS:
+
+ /*
+ * Do not count these rows as live, just like lazy_scan_prune
+ */
+ break;
+ default:
+ elog(ERROR, "unexpected HeapTupleSatisfiesVacuum result");
+ break;
+ }
+
+ }
+
+ vacrel->offnum = InvalidOffsetNumber;
+
+ if (has_tuple_needs_freeze)
+ {
+ /*
+ * Current non-aggressive VACUUM operation definitely won't be able to
+ * advance relfrozenxid or relminmxid
+ */
+ Assert(!vacrel->aggressive);
+ vacrel->freeze_cutoffs_valid = false;
+ }
+
+ /*
+ * Now save details of the LP_DEAD items from the page in the dead_items
+ * array iff VACUUM uses two-pass strategy case
+ */
+ if (vacrel->nindexes == 0)
+ {
+ /*
+ * We are not prepared to handle the corner case where a single pass
+ * strategy VACUUM cannot get a cleanup lock, and we then find LP_DEAD
+ * items. Count the LP_DEAD items as if they were DEAD tuples with
+ * storage that we cannot prune away. This is slightly inaccurate,
+ * but it hardly seems worth having dedicated handling just for this
+ * case.
+ *
+ * There is no fundamental reason why we must take the easy way out
+ * like this. Finding a way to make these LP_DEAD items get set to
+ * LP_UNUSED would be less valuable and more complicated than it is in
+ * the two-pass strategy case, since it would necessitate that we
+ * repeat our lazy_scan_heap caller's page-at-a-time/one-pass-strategy
+ * heap vacuuming steps. Whereas in the two-pass strategy case,
+ * lazy_vacuum_heap_rel will set the LP_DEAD items to LP_UNUSED. It
+ * must always deal with things like remaining DEAD tuples with
+ * storage, new LP_DEAD items that we didn't see earlier on, etc.
+ */
+ if (lpdead_items > 0)
+ *hastup = true;
+ *hasfreespace = true;
+ num_tuples += lpdead_items;
+ /* TODO HEAPTUPLE_DEAD style instrumentation needed here, too */
+ }
+ else if (lpdead_items > 0)
+ {
+ LVDeadItems *dead_items = vacrel->dead_items;
+ ItemPointerData tmp;
+
+ vacrel->lpdead_item_pages++;
+
+ ItemPointerSetBlockNumber(&tmp, blkno);
+
+ for (int i = 0; i < lpdead_items; i++)
+ {
+ ItemPointerSetOffsetNumber(&tmp, deadoffsets[i]);
+ dead_items->items[dead_items->num_items++] = tmp;
+ }
+
+ Assert(dead_items->num_items <= dead_items->max_items);
+ pgstat_progress_update_param(PROGRESS_VACUUM_NUM_DEAD_TUPLES,
+ dead_items->num_items);
+
+ vacrel->lpdead_items += lpdead_items;
+ }
+ else
+ {
+ /*
+ * Caller won't be vacuuming this page later, so tell it to record
+ * page's freespace in the FSM now
+ */
+ *hasfreespace = true;
+ }
+
+ /*
+ * Finally, add relevant page-local counts to whole-VACUUM counts
+ */
+ vacrel->new_dead_tuples += new_dead_tuples;
+ vacrel->num_tuples += num_tuples;
+ vacrel->live_tuples += live_tuples;
+
+ /* Caller won't need to call lazy_scan_prune with same page */
+ return true;
+}
+
/*
* Remove the collected garbage tuples from the table and its indexes.
*
@@ -2500,67 +2775,6 @@ lazy_vacuum_heap_page(LVRelState *vacrel, BlockNumber blkno, Buffer buffer,
return index;
}
-/*
- * lazy_check_needs_freeze() -- scan page to see if any tuples
- * need to be cleaned to avoid wraparound
- *
- * Returns true if the page needs to be vacuumed using cleanup lock.
- * Also returns a flag indicating whether page contains any tuples at all.
- */
-static bool
-lazy_check_needs_freeze(Buffer buf, bool *hastup, LVRelState *vacrel)
-{
- Page page = BufferGetPage(buf);
- OffsetNumber offnum,
- maxoff;
- HeapTupleHeader tupleheader;
-
- *hastup = false;
-
- /*
- * New and empty pages, obviously, don't contain tuples. We could make
- * sure that the page is registered in the FSM, but it doesn't seem worth
- * waiting for a cleanup lock just for that, especially because it's
- * likely that the pin holder will do so.
- */
- if (PageIsNew(page) || PageIsEmpty(page))
- return false;
-
- maxoff = PageGetMaxOffsetNumber(page);
- for (offnum = FirstOffsetNumber;
- offnum <= maxoff;
- offnum = OffsetNumberNext(offnum))
- {
- ItemId itemid;
-
- /*
- * Set the offset number so that we can display it along with any
- * error that occurred while processing this tuple.
- */
- vacrel->offnum = offnum;
- itemid = PageGetItemId(page, offnum);
-
- /* this should match hastup test in count_nondeletable_pages() */
- if (ItemIdIsUsed(itemid))
- *hastup = true;
-
- /* dead and redirect items never need freezing */
- if (!ItemIdIsNormal(itemid))
- continue;
-
- tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
-
- if (heap_tuple_needs_freeze(tupleheader, vacrel->FreezeLimit,
- vacrel->MultiXactCutoff, buf))
- break;
- } /* scan along page */
-
- /* Clear the offset information once we have processed the given page. */
- vacrel->offnum = InvalidOffsetNumber;
-
- return (offnum <= maxoff);
-}
-
/*
* Trigger the failsafe to avoid wraparound failure when vacrel table has a
* relfrozenxid and/or relminmxid that is dangerously far in the past.
@@ -2655,7 +2869,7 @@ do_parallel_lazy_cleanup_all_indexes(LVRelState *vacrel)
*/
vacrel->lps->lvshared->reltuples = vacrel->new_rel_tuples;
vacrel->lps->lvshared->estimated_count =
- (vacrel->tupcount_pages < vacrel->rel_pages);
+ (vacrel->scanned_pages < vacrel->rel_pages);
/* Determine the number of parallel workers to launch */
if (vacrel->lps->lvshared->first_time)
@@ -2972,7 +3186,7 @@ lazy_cleanup_all_indexes(LVRelState *vacrel)
{
double reltuples = vacrel->new_rel_tuples;
bool estimated_count =
- vacrel->tupcount_pages < vacrel->rel_pages;
+ vacrel->scanned_pages < vacrel->rel_pages;
for (int idx = 0; idx < vacrel->nindexes; idx++)
{
@@ -3123,7 +3337,9 @@ lazy_cleanup_one_index(Relation indrel, IndexBulkDeleteResult *istat,
* should_attempt_truncation - should we attempt to truncate the heap?
*
* Don't even think about it unless we have a shot at releasing a goodly
- * number of pages. Otherwise, the time taken isn't worth it.
+ * number of pages. Otherwise, the time taken isn't worth it, mainly because
+ * an AccessExclusive lock must be replayed on any hot standby, where it can
+ * be particularly disruptive.
*
* Also don't attempt it if wraparound failsafe is in effect. It's hard to
* predict how long lazy_truncate_heap will take. Don't take any chances.
diff --git a/src/test/isolation/expected/vacuum-reltuples.out b/src/test/isolation/expected/vacuum-reltuples.out
index cdbe7f3a6..ce55376e7 100644
--- a/src/test/isolation/expected/vacuum-reltuples.out
+++ b/src/test/isolation/expected/vacuum-reltuples.out
@@ -45,7 +45,7 @@ step stats:
relpages|reltuples
--------+---------
- 1| 20
+ 1| 21
(1 row)
diff --git a/src/test/isolation/specs/vacuum-reltuples.spec b/src/test/isolation/specs/vacuum-reltuples.spec
index ae2f79b8f..a2a461f2f 100644
--- a/src/test/isolation/specs/vacuum-reltuples.spec
+++ b/src/test/isolation/specs/vacuum-reltuples.spec
@@ -2,9 +2,10 @@
# to page pins. We absolutely need to avoid setting reltuples=0 in
# such cases, since that interferes badly with planning.
#
-# Expected result in second permutation is 20 tuples rather than 21 as
-# for the others, because vacuum should leave the previous result
-# (from before the insert) in place.
+# Expected result for all three permutation is 21 tuples, including
+# the second permutation. VACUUM is able to count the concurrently
+# inserted tuple in its final reltuples, even when a cleanup lock
+# cannot be acquired on the affected heap page.
setup {
create table smalltbl
--
2.30.2
[application/octet-stream] v3-0002-Improve-log_autovacuum_min_duration-output.patch (14.7K, ../../CAH2-Wz=c8LUnMuE1ioU=eLbfB4-7hNPu_yBpPyA1WRrHXLRaOQ@mail.gmail.com/3-v3-0002-Improve-log_autovacuum_min_duration-output.patch)
download | inline diff:
From 4affd72e80405f6593866c21391789a5afe471f0 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Sun, 21 Nov 2021 14:47:11 -0800
Subject: [PATCH v3 2/2] Improve log_autovacuum_min_duration output.
Add instrumentation of "missed dead tuples", and the number of pages
that had at least one such tuple. These are fully DEAD (not just
RECENTLY_DEAD) tuples with storage that could not be pruned due to an
inability to acquire a cleanup lock. This is a replacement for the
"skipped due to pin" instrumentation removed by the previous commit.
Note that the new instrumentation doesn't say anything about pages that
we failed to acquire a cleanup lock on when we see that there were no
missed dead tuples on the page.
Also report on visibility map pages skipped by VACUUM, without regard
for whether the pages were all-frozen or just all-visible.
Also report when and how relfrozenxid is advanced by VACUUM, including
non-aggressive VACUUM. Apart from being useful on its own, this might
enable future work that teaches non-aggressive VACUUM to be more
concerned about advancing relfrozenxid sooner rather than later.
Also enhance how we report OldestXmin cutoff by putting it in context:
show how far behind it is at the _end_ of the VACUUM operation.
Deliberately don't do anything with VACUUM VERBOSE in this commit, since
a pending patch will generalize the log_autovacuum_min_duration code to
produce VACUUM VERBOSE output as well [1]. That'll get committed first.
[1] https://commitfest.postgresql.org/36/3431/
---
src/include/commands/vacuum.h | 2 +
src/backend/access/heap/vacuumlazy.c | 100 +++++++++++++++++++--------
src/backend/commands/analyze.c | 3 +
src/backend/commands/vacuum.c | 9 +++
4 files changed, 84 insertions(+), 30 deletions(-)
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index 4cfd52eaf..bc625463e 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -263,6 +263,8 @@ extern void vac_update_relstats(Relation relation,
bool hasindex,
TransactionId frozenxid,
MultiXactId minmulti,
+ bool *frozenxid_updated,
+ bool *minmulti_updated,
bool in_outer_xact);
extern void vacuum_set_xid_limits(Relation rel,
int freeze_min_age, int freeze_table_age,
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 1fb8735a2..56da89f04 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -330,6 +330,7 @@ typedef struct LVRelState
BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber pages_removed; /* pages remove by truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
+ BlockNumber missed_dead_pages; /* # pages with missed dead tuples */
BlockNumber nonempty_pages; /* actually, last nonempty page + 1 */
/* Statistics output by us, for table */
@@ -343,8 +344,8 @@ typedef struct LVRelState
/* Counters that follow are only for scanned_pages */
int64 tuples_deleted; /* # deleted from table */
int64 lpdead_items; /* # deleted from indexes */
- int64 new_dead_tuples; /* new estimated total # of dead items in
- * table */
+ int64 recently_dead_tuples; /* # dead, but not yet removable */
+ int64 missed_dead_tuples; /* # removable, but not removed */
int64 num_tuples; /* total number of nonremovable tuples */
int64 live_tuples; /* live tuples (reltuples estimate) */
} LVRelState;
@@ -472,6 +473,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
double read_rate,
write_rate;
bool aggressive;
+ bool frozenxid_updated,
+ minmulti_updated;
BlockNumber orig_rel_pages;
char **indnames = NULL;
TransactionId xidFullScanLimit;
@@ -681,9 +684,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
/* Cannot advance relfrozenxid/relminmxid -- just update pg_class */
Assert(!aggressive);
+ frozenxid_updated = minmulti_updated = false;
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
new_rel_allvisible, vacrel->nindexes > 0,
- InvalidTransactionId, InvalidMultiXactId, false);
+ InvalidTransactionId, InvalidMultiXactId,
+ NULL, NULL, false);
}
else
{
@@ -692,7 +697,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
orig_rel_pages);
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
new_rel_allvisible, vacrel->nindexes > 0,
- FreezeLimit, MultiXactCutoff, false);
+ FreezeLimit, MultiXactCutoff,
+ &frozenxid_updated, &minmulti_updated, false);
}
/*
@@ -708,7 +714,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
pgstat_report_vacuum(RelationGetRelid(rel),
rel->rd_rel->relisshared,
Max(new_live_tuples, 0),
- vacrel->new_dead_tuples);
+ vacrel->recently_dead_tuples +
+ vacrel->missed_dead_tuples);
pgstat_progress_end_command();
/* and log the action if appropriate */
@@ -722,6 +729,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
StringInfoData buf;
char *msgfmt;
+ int32 diff;
TimestampDifference(starttime, endtime, &secs, &usecs);
@@ -768,16 +776,40 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->relnamespace,
vacrel->relname,
vacrel->num_index_scans);
- appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped frozen\n"),
+ appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped using visibility map (%.2f%% of total)\n"),
vacrel->pages_removed,
vacrel->rel_pages,
- vacrel->frozenskipped_pages);
+ orig_rel_pages - vacrel->scanned_pages,
+ orig_rel_pages == 0 ? 0 :
+ 100.0 * (orig_rel_pages - vacrel->scanned_pages) / orig_rel_pages);
appendStringInfo(&buf,
- _("tuples: %lld removed, %lld remain, %lld are dead but not yet removable, oldest xmin: %u\n"),
+ _("tuples: %lld removed, %lld remain, %lld are dead but not yet removable\n"),
(long long) vacrel->tuples_deleted,
(long long) vacrel->new_rel_tuples,
- (long long) vacrel->new_dead_tuples,
- OldestXmin);
+ (long long) vacrel->recently_dead_tuples);
+ if (vacrel->missed_dead_tuples > 0)
+ appendStringInfo(&buf,
+ _("tuples missed: %lld dead from %u contended pages\n"),
+ (long long) vacrel->missed_dead_tuples,
+ vacrel->missed_dead_pages);
+ diff = (int32) (ReadNextTransactionId() - OldestXmin);
+ appendStringInfo(&buf,
+ _("removal cutoff: oldest xmin was %u, which is now %d xact IDs behind\n"),
+ OldestXmin, diff);
+ if (frozenxid_updated)
+ {
+ diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
+ appendStringInfo(&buf,
+ _("relfrozenxid: advanced by %d xact IDs, new value: %u\n"),
+ diff, FreezeLimit);
+ }
+ if (minmulti_updated)
+ {
+ diff = (int32) (MultiXactCutoff - vacrel->relminmxid);
+ appendStringInfo(&buf,
+ _("relminmxid: advanced by %d multixact IDs, new value: %u\n"),
+ diff, MultiXactCutoff);
+ }
if (orig_rel_pages > 0)
{
if (vacrel->do_index_vacuuming)
@@ -935,13 +967,15 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params)
vacrel->frozenskipped_pages = 0;
vacrel->pages_removed = 0;
vacrel->lpdead_item_pages = 0;
+ vacrel->missed_dead_pages = 0;
vacrel->nonempty_pages = 0;
/* Initialize instrumentation counters */
vacrel->num_index_scans = 0;
vacrel->tuples_deleted = 0;
vacrel->lpdead_items = 0;
- vacrel->new_dead_tuples = 0;
+ vacrel->recently_dead_tuples = 0;
+ vacrel->missed_dead_tuples = 0;
vacrel->num_tuples = 0;
vacrel->live_tuples = 0;
@@ -1485,7 +1519,8 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params)
* (unlikely) scenario that new_live_tuples is -1, take it as zero.
*/
vacrel->new_rel_tuples =
- Max(vacrel->new_live_tuples, 0) + vacrel->new_dead_tuples;
+ Max(vacrel->new_live_tuples, 0) + vacrel->recently_dead_tuples +
+ vacrel->missed_dead_tuples;
/*
* Release any remaining pin on visibility map page.
@@ -1549,7 +1584,8 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params)
initStringInfo(&buf);
appendStringInfo(&buf,
_("%lld dead row versions cannot be removed yet, oldest xmin: %u\n"),
- (long long) vacrel->new_dead_tuples, vacrel->OldestXmin);
+ (long long) vacrel->recently_dead_tuples,
+ vacrel->OldestXmin);
appendStringInfo(&buf, _("%s."), pg_rusage_show(&ru0));
ereport(elevel,
@@ -1731,7 +1767,7 @@ lazy_scan_prune(LVRelState *vacrel,
HTSV_Result res;
int tuples_deleted,
lpdead_items,
- new_dead_tuples,
+ recently_dead_tuples,
num_tuples,
live_tuples;
int nnewlpdead;
@@ -1748,7 +1784,7 @@ retry:
/* Initialize (or reset) page-level counters */
tuples_deleted = 0;
lpdead_items = 0;
- new_dead_tuples = 0;
+ recently_dead_tuples = 0;
num_tuples = 0;
live_tuples = 0;
@@ -1907,11 +1943,11 @@ retry:
case HEAPTUPLE_RECENTLY_DEAD:
/*
- * If tuple is recently deleted then we must not remove it
- * from relation. (We only remove items that are LP_DEAD from
+ * If tuple is recently dead then we must not remove it from
+ * the relation. (We only remove items that are LP_DEAD from
* pruning.)
*/
- new_dead_tuples++;
+ recently_dead_tuples++;
prunestate->all_visible = false;
break;
case HEAPTUPLE_INSERT_IN_PROGRESS:
@@ -2087,7 +2123,7 @@ retry:
/* Finally, add page-local counts to whole-VACUUM counts */
vacrel->tuples_deleted += tuples_deleted;
vacrel->lpdead_items += lpdead_items;
- vacrel->new_dead_tuples += new_dead_tuples;
+ vacrel->recently_dead_tuples += recently_dead_tuples;
vacrel->num_tuples += num_tuples;
vacrel->live_tuples += live_tuples;
}
@@ -2141,7 +2177,8 @@ lazy_scan_noprune(LVRelState *vacrel,
int lpdead_items,
num_tuples,
live_tuples,
- new_dead_tuples;
+ recently_dead_tuples,
+ missed_dead_tuples;
HeapTupleHeader tupleheader;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
@@ -2153,7 +2190,8 @@ lazy_scan_noprune(LVRelState *vacrel,
lpdead_items = 0;
num_tuples = 0;
live_tuples = 0;
- new_dead_tuples = 0;
+ recently_dead_tuples = 0;
+ missed_dead_tuples = 0;
maxoff = PageGetMaxOffsetNumber(page);
for (offnum = FirstOffsetNumber;
@@ -2222,16 +2260,15 @@ lazy_scan_noprune(LVRelState *vacrel,
/*
* There is some useful work for pruning to do, that won't be
* done due to failure to get a cleanup lock.
- *
- * TODO Add dedicated instrumentation for this case
*/
+ missed_dead_tuples++;
break;
case HEAPTUPLE_RECENTLY_DEAD:
/*
- * Count in new_dead_tuples, just like lazy_scan_prune
+ * Count in recently_dead_tuples, just like lazy_scan_prune
*/
- new_dead_tuples++;
+ recently_dead_tuples++;
break;
case HEAPTUPLE_INSERT_IN_PROGRESS:
@@ -2286,7 +2323,7 @@ lazy_scan_noprune(LVRelState *vacrel,
*hastup = true;
*hasfreespace = true;
num_tuples += lpdead_items;
- /* TODO HEAPTUPLE_DEAD style instrumentation needed here, too */
+ missed_dead_tuples += lpdead_items;
}
else if (lpdead_items > 0)
{
@@ -2321,9 +2358,12 @@ lazy_scan_noprune(LVRelState *vacrel,
/*
* Finally, add relevant page-local counts to whole-VACUUM counts
*/
- vacrel->new_dead_tuples += new_dead_tuples;
+ vacrel->recently_dead_tuples += recently_dead_tuples;
+ vacrel->missed_dead_tuples += missed_dead_tuples;
vacrel->num_tuples += num_tuples;
vacrel->live_tuples += live_tuples;
+ if (missed_dead_tuples > 0)
+ vacrel->missed_dead_pages++;
/* Caller won't need to call lazy_scan_prune with same page */
return true;
@@ -2397,8 +2437,8 @@ lazy_vacuum(LVRelState *vacrel)
* dead_items space is not CPU cache resident.
*
* We don't take any special steps to remember the LP_DEAD items (such
- * as counting them in new_dead_tuples report to the stats collector)
- * when the optimization is applied. Though the accounting used in
+ * as counting them in our final report to the stats collector) when
+ * the optimization is applied. Though the accounting used in
* analyze.c's acquire_sample_rows() will recognize the same LP_DEAD
* items as dead rows in its own stats collector report, that's okay.
* The discrepancy should be negligible. If this optimization is ever
@@ -4058,7 +4098,7 @@ update_index_statistics(LVRelState *vacrel)
false,
InvalidTransactionId,
InvalidMultiXactId,
- false);
+ NULL, NULL, false);
}
}
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index cd77907fc..afd1cb8f5 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -651,6 +651,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
hasindex,
InvalidTransactionId,
InvalidMultiXactId,
+ NULL, NULL,
in_outer_xact);
/* Same for indexes */
@@ -667,6 +668,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
false,
InvalidTransactionId,
InvalidMultiXactId,
+ NULL, NULL,
in_outer_xact);
}
}
@@ -679,6 +681,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
vac_update_relstats(onerel, -1, totalrows,
0, hasindex, InvalidTransactionId,
InvalidMultiXactId,
+ NULL, NULL,
in_outer_xact);
}
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 5c4bc15b4..8bd4bd12c 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -1308,6 +1308,7 @@ vac_update_relstats(Relation relation,
BlockNumber num_all_visible_pages,
bool hasindex, TransactionId frozenxid,
MultiXactId minmulti,
+ bool *frozenxid_updated, bool *minmulti_updated,
bool in_outer_xact)
{
Oid relid = RelationGetRelid(relation);
@@ -1383,22 +1384,30 @@ vac_update_relstats(Relation relation,
* This should match vac_update_datfrozenxid() concerning what we consider
* to be "in the future".
*/
+ if (frozenxid_updated)
+ *frozenxid_updated = false;
if (TransactionIdIsNormal(frozenxid) &&
pgcform->relfrozenxid != frozenxid &&
(TransactionIdPrecedes(pgcform->relfrozenxid, frozenxid) ||
TransactionIdPrecedes(ReadNextTransactionId(),
pgcform->relfrozenxid)))
{
+ if (frozenxid_updated)
+ *frozenxid_updated = true;
pgcform->relfrozenxid = frozenxid;
dirty = true;
}
/* Similarly for relminmxid */
+ if (minmulti_updated)
+ *minmulti_updated = false;
if (MultiXactIdIsValid(minmulti) &&
pgcform->relminmxid != minmulti &&
(MultiXactIdPrecedes(pgcform->relminmxid, minmulti) ||
MultiXactIdPrecedes(ReadNextMultiXactId(), pgcform->relminmxid)))
{
+ if (minmulti_updated)
+ *minmulti_updated = true;
pgcform->relminmxid = minmulti;
dirty = true;
}
--
2.30.2
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-12-15 20:26 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2021-12-15 20:26 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Masahiko Sawada <[email protected]>
On Fri, Dec 10, 2021 at 1:48 PM Peter Geoghegan <[email protected]> wrote:
> * I'm still working on the optimization that we discussed on this
> thread: the optimization that allows the final relfrozenxid (that we
> set in pg_class) to be determined dynamically, based on the actual
> XIDs we observed in the table (we don't just naively use FreezeLimit).
Attached is v4 of the patch series, which now includes this
optimization, broken out into its own patch. In addition, it includes
a prototype of opportunistic freezing.
My emphasis here has been on making non-aggressive VACUUMs *always*
advance relfrozenxid, outside of certain obvious edge cases. And so
with all the patches applied, up to and including the opportunistic
freezing patch, every autovacuum of every table manages to advance
relfrozenxid during benchmarking -- usually to a fairly recent value.
I've focussed on making aggressive VACUUMs (especially anti-wraparound
autovacuums) a rare occurrence, for truly exceptional cases (e.g.,
user keeps canceling autovacuums, maybe due to automated script that
performs DDL). That has taken priority over other goals, for now.
There is a kind of virtuous circle here, where successive
non-aggressive autovacuums never fall behind on freezing, and so never
fail to advance relfrozenxid (there are never any
all_visible-but-not-all_frozen pages, and we can cope with not
acquiring a cleanup lock quite well). When VACUUM chooses to freeze a
tuple opportunistically, the frozen XIDs naturally cannot hold back
the final safe relfrozenxid for the relation. Opportunistic freezing
avoids setting all_visible (without setting all_frozen) in the
visibility map. It's impossible for VACUUM to just set a page to
all_visible now, which seems like an essential part of making a decent
amount of relfrozenxid advancement take place in almost every VACUUM
operation.
Here is an example of what I'm calling a virtuous circle -- all
pgbench_history autovacuums look like this with the patch applied:
LOG: automatic vacuum of table "regression.public.pgbench_history":
index scans: 0
pages: 0 removed, 35503 remain, 31930 skipped using visibility map
(89.94% of total)
tuples: 0 removed, 5568687 remain (547976 newly frozen), 0 are
dead but not yet removable
removal cutoff: oldest xmin was 5570281, which is now 1177 xact IDs behind
relfrozenxid: advanced by 546618 xact IDs, new value: 5565226
index scan not needed: 0 pages from table (0.00% of total) had 0
dead item identifiers removed
I/O timings: read: 0.003 ms, write: 0.000 ms
avg read rate: 0.068 MB/s, avg write rate: 0.068 MB/s
buffer usage: 7169 hits, 1 misses, 1 dirtied
WAL usage: 7043 records, 1 full page images, 6974928 bytes
system usage: CPU: user: 0.10 s, system: 0.00 s, elapsed: 0.11 s
Note that relfrozenxid is almost the same as oldest xmin here. Note also
that the log output shows the number of tuples newly frozen. I see the
same general trends with *every* pgbench_history autovacuum. Actually,
with every autovacuum. The history table tends to have ultra-recent
relfrozenxid values, which isn't always what we see, but that
difference may not matter. As far as I can tell, we can expect
practically every table to have a relfrozenxid that would (at least
traditionally) be considered very safe/recent. Barring weird
application issues that make it totally impossible to advance
relfrozenxid (e.g., idle cursors that hold onto a buffer pin forever),
it seems as if relfrozenxid will now steadily march forward. Sure,
relfrozenxid advancement might be held by the occasional inability to
acquire a cleanup lock, but the effect isn't noticeable over time;
what are the chances that a cleanup lock won't be available on the
same page (with the same old XID) more than once or twice? The odds of
that happening become astronomically tiny, long before there is any
real danger (barring pathological cases).
In the past, we've always talked about opportunistic freezing as a way
of avoiding re-dirtying heap pages during successive VACUUM operations
-- especially as a way of lowering the total volume of WAL. While I
agree that that's important, I have deliberately ignored it for now,
preferring to focus on the relfrozenxid stuff, and smoothing out the
cost of freezing (avoiding big shocks from aggressive/anti-wraparound
autovacuums). I care more about stable performance than absolute
throughput, but even still I believe that the approach I've taken to
opportunistic freezing is probably too aggressive. But it's dead
simple, which will make it easier to understand and discuss the issue
of central importance. It may be possible to optimize the WAL-logging
used during freezing, getting the cost down to the point where
freezing early just isn't a concern. The current prototype adds extra
WAL overhead, to be sure, but even that's not wildly unreasonable (you
make some of it back on FPIs, depending on the workload -- especially
with tables like pgbench_history, where delaying freezing is a total loss).
--
Peter Geoghegan
Attachments:
[application/x-patch] v4-0002-Improve-log_autovacuum_min_duration-output.patch (15.4K, ../../CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com/2-v4-0002-Improve-log_autovacuum_min_duration-output.patch)
download | inline diff:
From 276122392aefcf0d7a079d7c7dc532228d495bd7 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Sun, 21 Nov 2021 14:47:11 -0800
Subject: [PATCH v4 2/5] Improve log_autovacuum_min_duration output.
Add instrumentation of "missed dead tuples", and the number of pages
that had at least one such tuple. These are fully DEAD (not just
RECENTLY_DEAD) tuples with storage that could not be pruned due to an
inability to acquire a cleanup lock. This is a replacement for the
"skipped due to pin" instrumentation removed by the previous commit.
Note that the new instrumentation doesn't say anything about pages that
we failed to acquire a cleanup lock on when we see that there were no
missed dead tuples on the page.
Also report on visibility map pages skipped by VACUUM, without regard
for whether the pages were all-frozen or just all-visible.
Also report when and how relfrozenxid is advanced by VACUUM, including
non-aggressive VACUUM. Apart from being useful on its own, this might
enable future work that teaches non-aggressive VACUUM to be more
concerned about advancing relfrozenxid sooner rather than later.
Also report number of tuples frozen. This will become more important
when the later patch to perform opportunistic tuple freezing is
committed.
Also enhance how we report OldestXmin cutoff by putting it in context:
show how far behind it is at the _end_ of the VACUUM operation.
Deliberately don't do anything with VACUUM VERBOSE in this commit, since
a pending patch will generalize the log_autovacuum_min_duration code to
produce VACUUM VERBOSE output as well [1]. That'll get committed first.
[1] https://commitfest.postgresql.org/36/3431/
---
src/include/commands/vacuum.h | 2 +
src/backend/access/heap/vacuumlazy.c | 108 +++++++++++++++++++--------
src/backend/commands/analyze.c | 3 +
src/backend/commands/vacuum.c | 9 +++
4 files changed, 91 insertions(+), 31 deletions(-)
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index 4cfd52eaf..bc625463e 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -263,6 +263,8 @@ extern void vac_update_relstats(Relation relation,
bool hasindex,
TransactionId frozenxid,
MultiXactId minmulti,
+ bool *frozenxid_updated,
+ bool *minmulti_updated,
bool in_outer_xact);
extern void vacuum_set_xid_limits(Relation rel,
int freeze_min_age, int freeze_table_age,
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index c6d3a483f..238e07a78 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -351,6 +351,7 @@ typedef struct LVRelState
BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber pages_removed; /* pages remove by truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
+ BlockNumber missed_dead_pages; /* # pages with missed dead tuples */
BlockNumber nonempty_pages; /* actually, last nonempty page + 1 */
/* Statistics output by us, for table */
@@ -363,9 +364,10 @@ typedef struct LVRelState
int num_index_scans;
/* Counters that follow are only for scanned_pages */
int64 tuples_deleted; /* # deleted from table */
+ int64 tuples_frozen; /* # frozen by us */
int64 lpdead_items; /* # deleted from indexes */
- int64 new_dead_tuples; /* new estimated total # of dead items in
- * table */
+ int64 recently_dead_tuples; /* # dead, but not yet removable */
+ int64 missed_dead_tuples; /* # removable, but not removed */
int64 num_tuples; /* total number of nonremovable tuples */
int64 live_tuples; /* live tuples (reltuples estimate) */
} LVRelState;
@@ -488,6 +490,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
write_rate;
bool aggressive,
skipwithvm;
+ bool frozenxid_updated,
+ minmulti_updated;
BlockNumber orig_rel_pages;
char **indnames = NULL;
TransactionId xidFullScanLimit;
@@ -705,9 +709,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
/* Cannot advance relfrozenxid/relminmxid -- just update pg_class */
Assert(!aggressive);
+ frozenxid_updated = minmulti_updated = false;
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
new_rel_allvisible, vacrel->nindexes > 0,
- InvalidTransactionId, InvalidMultiXactId, false);
+ InvalidTransactionId, InvalidMultiXactId,
+ NULL, NULL, false);
}
else
{
@@ -716,7 +722,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
orig_rel_pages);
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
new_rel_allvisible, vacrel->nindexes > 0,
- FreezeLimit, MultiXactCutoff, false);
+ FreezeLimit, MultiXactCutoff,
+ &frozenxid_updated, &minmulti_updated, false);
}
/*
@@ -732,7 +739,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
pgstat_report_vacuum(RelationGetRelid(rel),
rel->rd_rel->relisshared,
Max(new_live_tuples, 0),
- vacrel->new_dead_tuples);
+ vacrel->recently_dead_tuples +
+ vacrel->missed_dead_tuples);
pgstat_progress_end_command();
/* and log the action if appropriate */
@@ -746,6 +754,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
StringInfoData buf;
char *msgfmt;
+ int32 diff;
TimestampDifference(starttime, endtime, &secs, &usecs);
@@ -792,16 +801,41 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->relnamespace,
vacrel->relname,
vacrel->num_index_scans);
- appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped frozen\n"),
+ appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped using visibility map (%.2f%% of total)\n"),
vacrel->pages_removed,
vacrel->rel_pages,
- vacrel->frozenskipped_pages);
+ orig_rel_pages - vacrel->scanned_pages,
+ orig_rel_pages == 0 ? 0 :
+ 100.0 * (orig_rel_pages - vacrel->scanned_pages) / orig_rel_pages);
appendStringInfo(&buf,
- _("tuples: %lld removed, %lld remain, %lld are dead but not yet removable, oldest xmin: %u\n"),
+ _("tuples: %lld removed, %lld remain (%lld newly frozen), %lld are dead but not yet removable\n"),
(long long) vacrel->tuples_deleted,
(long long) vacrel->new_rel_tuples,
- (long long) vacrel->new_dead_tuples,
- OldestXmin);
+ (long long) vacrel->tuples_frozen,
+ (long long) vacrel->recently_dead_tuples);
+ if (vacrel->missed_dead_tuples > 0)
+ appendStringInfo(&buf,
+ _("tuples missed: %lld dead from %u contended pages\n"),
+ (long long) vacrel->missed_dead_tuples,
+ vacrel->missed_dead_pages);
+ diff = (int32) (ReadNextTransactionId() - OldestXmin);
+ appendStringInfo(&buf,
+ _("removal cutoff: oldest xmin was %u, which is now %d xact IDs behind\n"),
+ OldestXmin, diff);
+ if (frozenxid_updated)
+ {
+ diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
+ appendStringInfo(&buf,
+ _("relfrozenxid: advanced by %d xact IDs, new value: %u\n"),
+ diff, FreezeLimit);
+ }
+ if (minmulti_updated)
+ {
+ diff = (int32) (MultiXactCutoff - vacrel->relminmxid);
+ appendStringInfo(&buf,
+ _("relminmxid: advanced by %d multixact IDs, new value: %u\n"),
+ diff, MultiXactCutoff);
+ }
if (orig_rel_pages > 0)
{
if (vacrel->do_index_vacuuming)
@@ -957,13 +991,16 @@ lazy_scan_heap(LVRelState *vacrel, bool skipwithvm, int nworkers)
vacrel->frozenskipped_pages = 0;
vacrel->pages_removed = 0;
vacrel->lpdead_item_pages = 0;
+ vacrel->missed_dead_pages = 0;
vacrel->nonempty_pages = 0;
/* Initialize instrumentation counters */
vacrel->num_index_scans = 0;
vacrel->tuples_deleted = 0;
+ vacrel->tuples_frozen = 0;
vacrel->lpdead_items = 0;
- vacrel->new_dead_tuples = 0;
+ vacrel->recently_dead_tuples = 0;
+ vacrel->missed_dead_tuples = 0;
vacrel->num_tuples = 0;
vacrel->live_tuples = 0;
@@ -1510,7 +1547,8 @@ lazy_scan_heap(LVRelState *vacrel, bool skipwithvm, int nworkers)
* (unlikely) scenario that new_live_tuples is -1, take it as zero.
*/
vacrel->new_rel_tuples =
- Max(vacrel->new_live_tuples, 0) + vacrel->new_dead_tuples;
+ Max(vacrel->new_live_tuples, 0) + vacrel->recently_dead_tuples +
+ vacrel->missed_dead_tuples;
/*
* Release any remaining pin on visibility map page.
@@ -1574,7 +1612,8 @@ lazy_scan_heap(LVRelState *vacrel, bool skipwithvm, int nworkers)
initStringInfo(&buf);
appendStringInfo(&buf,
_("%lld dead row versions cannot be removed yet, oldest xmin: %u\n"),
- (long long) vacrel->new_dead_tuples, vacrel->OldestXmin);
+ (long long) vacrel->recently_dead_tuples,
+ vacrel->OldestXmin);
appendStringInfo(&buf, _("%s."), pg_rusage_show(&ru0));
ereport(elevel,
@@ -1756,7 +1795,7 @@ lazy_scan_prune(LVRelState *vacrel,
HTSV_Result res;
int tuples_deleted,
lpdead_items,
- new_dead_tuples,
+ recently_dead_tuples,
num_tuples,
live_tuples;
int nnewlpdead;
@@ -1773,7 +1812,7 @@ retry:
/* Initialize (or reset) page-level counters */
tuples_deleted = 0;
lpdead_items = 0;
- new_dead_tuples = 0;
+ recently_dead_tuples = 0;
num_tuples = 0;
live_tuples = 0;
@@ -1932,11 +1971,11 @@ retry:
case HEAPTUPLE_RECENTLY_DEAD:
/*
- * If tuple is recently deleted then we must not remove it
- * from relation. (We only remove items that are LP_DEAD from
+ * If tuple is recently dead then we must not remove it from
+ * the relation. (We only remove items that are LP_DEAD from
* pruning.)
*/
- new_dead_tuples++;
+ recently_dead_tuples++;
prunestate->all_visible = false;
break;
case HEAPTUPLE_INSERT_IN_PROGRESS:
@@ -2111,8 +2150,9 @@ retry:
/* Finally, add page-local counts to whole-VACUUM counts */
vacrel->tuples_deleted += tuples_deleted;
+ vacrel->tuples_frozen += nfrozen;
vacrel->lpdead_items += lpdead_items;
- vacrel->new_dead_tuples += new_dead_tuples;
+ vacrel->recently_dead_tuples += recently_dead_tuples;
vacrel->num_tuples += num_tuples;
vacrel->live_tuples += live_tuples;
}
@@ -2165,7 +2205,8 @@ lazy_scan_noprune(LVRelState *vacrel,
int lpdead_items,
num_tuples,
live_tuples,
- new_dead_tuples;
+ recently_dead_tuples,
+ missed_dead_tuples;
HeapTupleHeader tupleheader;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
@@ -2177,7 +2218,8 @@ lazy_scan_noprune(LVRelState *vacrel,
lpdead_items = 0;
num_tuples = 0;
live_tuples = 0;
- new_dead_tuples = 0;
+ recently_dead_tuples = 0;
+ missed_dead_tuples = 0;
maxoff = PageGetMaxOffsetNumber(page);
for (offnum = FirstOffsetNumber;
@@ -2250,16 +2292,15 @@ lazy_scan_noprune(LVRelState *vacrel,
/*
* There is some useful work for pruning to do, that won't be
* done due to failure to get a cleanup lock.
- *
- * TODO Add dedicated instrumentation for this case
*/
+ missed_dead_tuples++;
break;
case HEAPTUPLE_RECENTLY_DEAD:
/*
- * Count in new_dead_tuples, just like lazy_scan_prune
+ * Count in recently_dead_tuples, just like lazy_scan_prune
*/
- new_dead_tuples++;
+ recently_dead_tuples++;
break;
case HEAPTUPLE_INSERT_IN_PROGRESS:
@@ -2287,13 +2328,15 @@ lazy_scan_noprune(LVRelState *vacrel,
*
* We are not prepared to handle the corner case where a single pass
* strategy VACUUM cannot get a cleanup lock, and we then find LP_DEAD
- * items.
+ * items. Count the LP_DEAD items as missed_dead_tuples instead. This
+ * is slightly dishonest, but it's better than maintaining code to do
+ * heap vacuuming for this one narrow corner case.
*/
if (lpdead_items > 0)
*hastup = true;
*hasfreespace = true;
num_tuples += lpdead_items;
- /* TODO HEAPTUPLE_DEAD style instrumentation needed here, too */
+ missed_dead_tuples += lpdead_items;
}
else if (lpdead_items > 0)
{
@@ -2328,9 +2371,12 @@ lazy_scan_noprune(LVRelState *vacrel,
/*
* Finally, add relevant page-local counts to whole-VACUUM counts
*/
- vacrel->new_dead_tuples += new_dead_tuples;
+ vacrel->recently_dead_tuples += recently_dead_tuples;
+ vacrel->missed_dead_tuples += missed_dead_tuples;
vacrel->num_tuples += num_tuples;
vacrel->live_tuples += live_tuples;
+ if (missed_dead_tuples > 0)
+ vacrel->missed_dead_pages++;
/* Caller won't need to call lazy_scan_prune with same page */
return true;
@@ -2404,8 +2450,8 @@ lazy_vacuum(LVRelState *vacrel)
* dead_items space is not CPU cache resident.
*
* We don't take any special steps to remember the LP_DEAD items (such
- * as counting them in new_dead_tuples report to the stats collector)
- * when the optimization is applied. Though the accounting used in
+ * as counting them in our final report to the stats collector) when
+ * the optimization is applied. Though the accounting used in
* analyze.c's acquire_sample_rows() will recognize the same LP_DEAD
* items as dead rows in its own stats collector report, that's okay.
* The discrepancy should be negligible. If this optimization is ever
@@ -4061,7 +4107,7 @@ update_index_statistics(LVRelState *vacrel)
false,
InvalidTransactionId,
InvalidMultiXactId,
- false);
+ NULL, NULL, false);
}
}
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index cd77907fc..afd1cb8f5 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -651,6 +651,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
hasindex,
InvalidTransactionId,
InvalidMultiXactId,
+ NULL, NULL,
in_outer_xact);
/* Same for indexes */
@@ -667,6 +668,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
false,
InvalidTransactionId,
InvalidMultiXactId,
+ NULL, NULL,
in_outer_xact);
}
}
@@ -679,6 +681,7 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
vac_update_relstats(onerel, -1, totalrows,
0, hasindex, InvalidTransactionId,
InvalidMultiXactId,
+ NULL, NULL,
in_outer_xact);
}
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 5c4bc15b4..8bd4bd12c 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -1308,6 +1308,7 @@ vac_update_relstats(Relation relation,
BlockNumber num_all_visible_pages,
bool hasindex, TransactionId frozenxid,
MultiXactId minmulti,
+ bool *frozenxid_updated, bool *minmulti_updated,
bool in_outer_xact)
{
Oid relid = RelationGetRelid(relation);
@@ -1383,22 +1384,30 @@ vac_update_relstats(Relation relation,
* This should match vac_update_datfrozenxid() concerning what we consider
* to be "in the future".
*/
+ if (frozenxid_updated)
+ *frozenxid_updated = false;
if (TransactionIdIsNormal(frozenxid) &&
pgcform->relfrozenxid != frozenxid &&
(TransactionIdPrecedes(pgcform->relfrozenxid, frozenxid) ||
TransactionIdPrecedes(ReadNextTransactionId(),
pgcform->relfrozenxid)))
{
+ if (frozenxid_updated)
+ *frozenxid_updated = true;
pgcform->relfrozenxid = frozenxid;
dirty = true;
}
/* Similarly for relminmxid */
+ if (minmulti_updated)
+ *minmulti_updated = false;
if (MultiXactIdIsValid(minmulti) &&
pgcform->relminmxid != minmulti &&
(MultiXactIdPrecedes(pgcform->relminmxid, minmulti) ||
MultiXactIdPrecedes(ReadNextMultiXactId(), pgcform->relminmxid)))
{
+ if (minmulti_updated)
+ *minmulti_updated = true;
pgcform->relminmxid = minmulti;
dirty = true;
}
--
2.30.2
[application/x-patch] v4-0004-Decouple-advancing-relfrozenxid-from-freezing.patch (28.6K, ../../CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com/3-v4-0004-Decouple-advancing-relfrozenxid-from-freezing.patch)
download | inline diff:
From 6465bbf843dc8ee549cea5cc6a15c68784098f53 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Mon, 22 Nov 2021 10:02:30 -0800
Subject: [PATCH v4 4/5] Decouple advancing relfrozenxid from freezing.
Stop using tuple freezing (and MultiXact freezing) tuple header cutoffs
to determine the final relfrozenxid (and relminmxid) values that we set
for heap relations in pg_class. Use "optimal" values instead.
Optimal values are the most recent values that are less than or equal to
any remaining XID/MultiXact in a tuple header (not counting frozen
xmin/xmax values). This is now kept track of by VACUUM. "Optimal"
values are always >= the tuple header FreezeLimit in an aggressive
VACUUM. For a non-aggressive VACUUM, they can be less than or greater
than the tuple header FreezeLimit cutoff (though we still often pass
invalid values to indicate that we cannot advance relfrozenxid during
the VACUUM).
---
src/include/access/heapam.h | 4 +-
src/include/access/heapam_xlog.h | 4 +-
src/include/commands/vacuum.h | 1 +
src/backend/access/heap/heapam.c | 186 ++++++++++++++++++++-------
src/backend/access/heap/vacuumlazy.c | 76 +++++++----
src/backend/commands/cluster.c | 5 +-
src/backend/commands/vacuum.c | 30 ++++-
7 files changed, 228 insertions(+), 78 deletions(-)
diff --git a/src/include/access/heapam.h b/src/include/access/heapam.h
index 417dd288e..0eb5c36a2 100644
--- a/src/include/access/heapam.h
+++ b/src/include/access/heapam.h
@@ -168,7 +168,9 @@ extern bool heap_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi);
extern bool heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi, Buffer buf);
+ MultiXactId cutoff_multi,
+ TransactionId *NewRelfrozenxid,
+ MultiXactId *NewRelminmxid, Buffer buf);
extern bool heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple);
extern void simple_heap_insert(Relation relation, HeapTuple tup);
diff --git a/src/include/access/heapam_xlog.h b/src/include/access/heapam_xlog.h
index ab9e873bc..b0ede623e 100644
--- a/src/include/access/heapam_xlog.h
+++ b/src/include/access/heapam_xlog.h
@@ -410,7 +410,9 @@ extern bool heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId cutoff_xid,
TransactionId cutoff_multi,
xl_heap_freeze_tuple *frz,
- bool *totally_frozen);
+ bool *totally_frozen,
+ TransactionId *NewRelfrozenxid,
+ MultiXactId *NewRelminmxid);
extern void heap_execute_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple *xlrec_tp);
extern XLogRecPtr log_heap_visible(RelFileNode rnode, Buffer heap_buffer,
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index 6eefe8129..114d6da89 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -271,6 +271,7 @@ extern bool vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff);
extern bool vacuum_xid_failsafe_check(TransactionId relfrozenxid,
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 0b4a46b31..d296a79ea 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -6078,12 +6078,24 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* FRM_RETURN_IS_MULTI
* The return value is a new MultiXactId to set as new Xmax.
* (caller must obtain proper infomask bits using GetMultiXactIdHintBits)
+ *
+ * "NewRelfrozenxid" is an output value; it's used to maintain target new
+ * relfrozenxid for the relation. It can be ignored unless "flags" contains
+ * either FRM_NOOP or FRM_RETURN_IS_MULTI, because we only handle multiXacts
+ * here. This follows the general convention: only track XIDs that will still
+ * be in the table after the ongoing VACUUM finishes. Note that it's up to
+ * caller to maintain this when the Xid return value is itself an Xid.
+ *
+ * Note that we cannot depend on xmin to maintain NewRelfrozenxid. We need to
+ * push maintenance of NewRelfrozenxid down this far, since in general xmin
+ * might have been frozen by an earlier VACUUM operation, in which case our
+ * caller will not have factored-in xmin when maintaining NewRelfrozenxid.
*/
static TransactionId
FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, MultiXactId cutoff_multi,
- uint16 *flags)
+ uint16 *flags, TransactionId *NewRelfrozenxid)
{
TransactionId xid = InvalidTransactionId;
int i;
@@ -6095,6 +6107,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
bool has_lockers;
TransactionId update_xid;
bool update_committed;
+ TransactionId tempNewRelfrozenxid;
*flags = 0;
@@ -6189,13 +6202,13 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
/* is there anything older than the cutoff? */
need_replace = false;
+ tempNewRelfrozenxid = *NewRelfrozenxid;
for (i = 0; i < nmembers; i++)
{
if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
- {
need_replace = true;
- break;
- }
+ if (TransactionIdPrecedes(members[i].xid, tempNewRelfrozenxid))
+ tempNewRelfrozenxid = members[i].xid;
}
/*
@@ -6204,6 +6217,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
*/
if (!need_replace)
{
+ *NewRelfrozenxid = tempNewRelfrozenxid;
*flags |= FRM_NOOP;
pfree(members);
return InvalidTransactionId;
@@ -6213,6 +6227,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* If the multi needs to be updated, figure out which members do we need
* to keep.
*/
+ tempNewRelfrozenxid = *NewRelfrozenxid;
nnewmembers = 0;
newmembers = palloc(sizeof(MultiXactMember) * nmembers);
has_lockers = false;
@@ -6294,7 +6309,11 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* list.)
*/
if (TransactionIdIsValid(update_xid))
+ {
newmembers[nnewmembers++] = members[i];
+ if (TransactionIdPrecedes(members[i].xid, tempNewRelfrozenxid))
+ tempNewRelfrozenxid = members[i].xid;
+ }
}
else
{
@@ -6304,6 +6323,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
{
/* running locker cannot possibly be older than the cutoff */
Assert(!TransactionIdPrecedes(members[i].xid, cutoff_xid));
+ Assert(!TransactionIdPrecedes(members[i].xid, *NewRelfrozenxid));
newmembers[nnewmembers++] = members[i];
has_lockers = true;
}
@@ -6332,6 +6352,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
if (update_committed)
*flags |= FRM_MARK_COMMITTED;
xid = update_xid;
+ /* Caller manages NewRelfrozenxid directly when we return an XID */
}
else
{
@@ -6341,6 +6362,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
*/
xid = MultiXactIdCreateFromMembers(nnewmembers, newmembers);
*flags |= FRM_RETURN_IS_MULTI;
+ *NewRelfrozenxid = tempNewRelfrozenxid;
}
pfree(newmembers);
@@ -6359,6 +6381,13 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* will be totally frozen after these operations are performed and false if
* more freezing will eventually be required.
*
+ * Also maintains *NewRelfrozenxid and *NewRelminmxid, which are the current
+ * target relfrozenxid and relminmxid for the relation. Assumption is that
+ * caller will actually go on to freeze as indicated by our *frz output, so
+ * any (xmin, xmax, xvac) XIDs that we indicate need to be frozen won't need
+ * to be counted here. Values are valid lower bounds at the point that the
+ * ongoing VACUUM finishes.
+ *
* Caller is responsible for setting the offset field, if appropriate.
*
* It is assumed that the caller has checked the tuple with
@@ -6383,7 +6412,9 @@ bool
heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi,
- xl_heap_freeze_tuple *frz, bool *totally_frozen_p)
+ xl_heap_freeze_tuple *frz, bool *totally_frozen_p,
+ TransactionId *NewRelfrozenxid,
+ MultiXactId *NewRelminmxid)
{
bool changed = false;
bool xmax_already_frozen = false;
@@ -6427,6 +6458,11 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
frz->t_infomask |= HEAP_XMIN_FROZEN;
changed = true;
}
+ else if (TransactionIdPrecedes(xid, *NewRelfrozenxid))
+ {
+ /* won't be frozen, but older than current NewRelfrozenxid */
+ *NewRelfrozenxid = xid;
+ }
}
/*
@@ -6444,10 +6480,11 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
{
TransactionId newxmax;
uint16 flags;
+ TransactionId temp = *NewRelfrozenxid;
newxmax = FreezeMultiXactId(xid, tuple->t_infomask,
relfrozenxid, relminmxid,
- cutoff_xid, cutoff_multi, &flags);
+ cutoff_xid, cutoff_multi, &flags, &temp);
freeze_xmax = (flags & FRM_INVALIDATE_XMAX);
@@ -6465,6 +6502,24 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
if (flags & FRM_MARK_COMMITTED)
frz->t_infomask |= HEAP_XMAX_COMMITTED;
changed = true;
+
+ if (TransactionIdPrecedes(newxmax, *NewRelfrozenxid))
+ {
+ /* New xmax is an XID older than new NewRelfrozenxid */
+ *NewRelfrozenxid = newxmax;
+ }
+ }
+ else if (flags & FRM_NOOP)
+ {
+ /*
+ * Changing nothing, so might have to ratchet back NewRelminmxid,
+ * NewRelfrozenxid, or both together
+ */
+ if (MultiXactIdIsValid(xid) &&
+ MultiXactIdPrecedes(xid, *NewRelminmxid))
+ *NewRelminmxid = xid;
+ if (TransactionIdPrecedes(temp, *NewRelfrozenxid))
+ *NewRelfrozenxid = temp;
}
else if (flags & FRM_RETURN_IS_MULTI)
{
@@ -6486,6 +6541,13 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
frz->xmax = newxmax;
changed = true;
+
+ /*
+ * New multixact might have remaining XID older than
+ * NewRelfrozenxid
+ */
+ if (TransactionIdPrecedes(temp, *NewRelfrozenxid))
+ *NewRelfrozenxid = temp;
}
}
else if (TransactionIdIsNormal(xid))
@@ -6513,7 +6575,14 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
freeze_xmax = true;
}
else
+ {
freeze_xmax = false;
+ if (TransactionIdPrecedes(xid, *NewRelfrozenxid))
+ {
+ /* won't be frozen, but older than current NewRelfrozenxid */
+ *NewRelfrozenxid = xid;
+ }
+ }
}
else if ((tuple->t_infomask & HEAP_XMAX_INVALID) ||
!TransactionIdIsValid(HeapTupleHeaderGetRawXmax(tuple)))
@@ -6560,6 +6629,9 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* was removed in PostgreSQL 9.0. Note that if we were to respect
* cutoff_xid here, we'd need to make surely to clear totally_frozen
* when we skipped freezing on that basis.
+ *
+ * Since we always freeze here, NewRelfrozenxid doesn't need to be
+ * maintained.
*/
if (TransactionIdIsNormal(xid))
{
@@ -6637,11 +6709,14 @@ heap_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple frz;
bool do_freeze;
bool tuple_totally_frozen;
+ TransactionId NewRelfrozenxid = FirstNormalTransactionId;
+ MultiXactId NewRelminmxid = FirstMultiXactId;
do_freeze = heap_prepare_freeze_tuple(tuple,
relfrozenxid, relminmxid,
cutoff_xid, cutoff_multi,
- &frz, &tuple_totally_frozen);
+ &frz, &tuple_totally_frozen,
+ &NewRelfrozenxid, &NewRelminmxid);
/*
* Note that because this is not a WAL-logged operation, we don't need to
@@ -7071,6 +7146,15 @@ heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
* Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
* are older than the specified cutoff XID or MultiXactId. If so, return true.
*
+ * Also maintains *NewRelfrozenxid and *NewRelminmxid, which are the current
+ * target relfrozenxid and relminmxid for the relation. Assumption is that
+ * caller will never freeze any of the XIDs from the tuple, even when we say
+ * that they should. If caller opts to go with our recommendation to freeze,
+ * then it must account for the fact that it shouldn't trust how we've set
+ * NewRelfrozenxid/NewRelminmxid. (In practice aggressive VACUUMs always take
+ * our recommendation because they must, and non-aggressive VACUUMs always opt
+ * to not freeze, preferring to ratchet back NewRelfrozenxid instead).
+ *
* It doesn't matter whether the tuple is alive or dead, we are checking
* to see if a tuple needs to be removed or frozen to avoid wraparound.
*
@@ -7079,74 +7163,86 @@ heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
*/
bool
heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi, Buffer buf)
+ MultiXactId cutoff_multi,
+ TransactionId *NewRelfrozenxid,
+ MultiXactId *NewRelminmxid, Buffer buf)
{
TransactionId xid;
+ bool needs_freeze = false;
xid = HeapTupleHeaderGetXmin(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *NewRelfrozenxid))
+ *NewRelfrozenxid = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ needs_freeze = true;
+ }
/*
* The considerations for multixacts are complicated; look at
* heap_prepare_freeze_tuple for justifications. This routine had better
* be in sync with that one!
+ *
+ * (Actually, we maintain NewRelminmxid differently here, because we
+ * assume that XIDs that should be frozen according to cutoff_xid won't
+ * be, whereas heap_prepare_freeze_tuple makes the opposite assumption.)
*/
if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
{
MultiXactId multi;
+ MultiXactMember *members;
+ int nmembers;
multi = HeapTupleHeaderGetRawXmax(tuple);
- if (!MultiXactIdIsValid(multi))
- {
- /* no xmax set, ignore */
- ;
- }
- else if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
+ if (MultiXactIdIsValid(multi) &&
+ MultiXactIdPrecedes(multi, *NewRelminmxid))
+ *NewRelminmxid = multi;
+
+ if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
return true;
else if (MultiXactIdPrecedes(multi, cutoff_multi))
- return true;
- else
+ needs_freeze = true;
+
+ /* need to check whether any member of the mxact is too old */
+ nmembers = GetMultiXactIdMembers(multi, &members, false,
+ HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
+
+ for (int i = 0; i < nmembers; i++)
{
- MultiXactMember *members;
- int nmembers;
- int i;
-
- /* need to check whether any member of the mxact is too old */
-
- nmembers = GetMultiXactIdMembers(multi, &members, false,
- HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
-
- for (i = 0; i < nmembers; i++)
- {
- if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
- {
- pfree(members);
- return true;
- }
- }
- if (nmembers > 0)
- pfree(members);
+ if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
+ needs_freeze = true;
+ if (TransactionIdPrecedes(members[i].xid, *NewRelfrozenxid))
+ *NewRelfrozenxid = xid;
}
+ if (nmembers > 0)
+ pfree(members);
}
else
{
xid = HeapTupleHeaderGetRawXmax(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *NewRelfrozenxid))
+ *NewRelfrozenxid = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ needs_freeze = true;
+ }
}
if (tuple->t_infomask & HEAP_MOVED)
{
xid = HeapTupleHeaderGetXvac(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *NewRelfrozenxid))
+ *NewRelfrozenxid = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ needs_freeze = true;
+ }
}
- return false;
+ return needs_freeze;
}
/*
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index da5b3f79a..c6facc9eb 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -331,8 +331,10 @@ typedef struct LVRelState
/* VACUUM operation's cutoff for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
- /* Are FreezeLimit/MultiXactCutoff still valid? */
- bool freeze_cutoffs_valid;
+
+ /* Track new pg_class.relfrozenxid/pg_class.relminmxid values */
+ TransactionId NewRelfrozenxid;
+ MultiXactId NewRelminmxid;
/* Error reporting state */
char *relnamespace;
@@ -501,6 +503,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
TransactionId OldestXmin;
+ MultiXactId OldestMxact;
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
@@ -537,8 +540,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
params->freeze_table_age,
params->multixact_freeze_min_age,
params->multixact_freeze_table_age,
- &OldestXmin, &FreezeLimit,
- &MultiXactCutoff);
+ &OldestXmin, &OldestMxact,
+ &FreezeLimit, &MultiXactCutoff);
skipwithvm = true;
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
@@ -602,8 +605,10 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->OldestXmin = OldestXmin;
vacrel->FreezeLimit = FreezeLimit;
vacrel->MultiXactCutoff = MultiXactCutoff;
- /* Track if cutoffs became invalid (possible in !aggressive case only) */
- vacrel->freeze_cutoffs_valid = true;
+
+ /* Initialize values used to advance relfrozenxid/relminmxid at the end */
+ vacrel->NewRelfrozenxid = OldestXmin;
+ vacrel->NewRelminmxid = OldestMxact;
vacrel->relnamespace = get_namespace_name(RelationGetNamespace(rel));
vacrel->relname = pstrdup(RelationGetRelationName(rel));
@@ -692,16 +697,18 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* Aggressive VACUUM must reliably advance relfrozenxid (and relminmxid).
* We are able to advance relfrozenxid in a non-aggressive VACUUM too,
* provided we didn't skip any all-visible (not all-frozen) pages using
- * the visibility map, and assuming that we didn't fail to get a cleanup
- * lock that made it unsafe with respect to FreezeLimit (or perhaps our
- * MultiXactCutoff) established for VACUUM operation.
+ * the visibility map. A non-aggressive VACUUM might only be able to
+ * advance relfrozenxid to an XID from before FreezeLimit (or a relminmxid
+ * from before MultiXactCutoff) when it wasn't possible to freeze some
+ * tuples due to our inability to acquire a cleanup lock, but the effect
+ * is usually insignificant -- NewRelfrozenxid value still has a decent
+ * chance of being much more recent that the existing relfrozenxid.
*
* NB: We must use orig_rel_pages, not vacrel->rel_pages, since we want
* the rel_pages used by lazy_scan_heap, which won't match when we
* happened to truncate the relation afterwards.
*/
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
- !vacrel->freeze_cutoffs_valid)
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
{
/* Cannot advance relfrozenxid/relminmxid -- just update pg_class */
Assert(!aggressive);
@@ -718,7 +725,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
orig_rel_pages);
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
new_rel_allvisible, vacrel->nindexes > 0,
- FreezeLimit, MultiXactCutoff,
+ vacrel->NewRelfrozenxid, vacrel->NewRelminmxid,
&frozenxid_updated, &minmulti_updated, false);
}
@@ -820,14 +827,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
OldestXmin, diff);
if (frozenxid_updated)
{
- diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
+ diff = (int32) (vacrel->NewRelfrozenxid - vacrel->relfrozenxid);
appendStringInfo(&buf,
_("relfrozenxid: advanced by %d xact IDs, new value: %u\n"),
- diff, FreezeLimit);
+ diff, vacrel->NewRelfrozenxid);
}
if (minmulti_updated)
{
- diff = (int32) (MultiXactCutoff - vacrel->relminmxid);
+ diff = (int32) (vacrel->NewRelminmxid - vacrel->relminmxid);
appendStringInfo(&buf,
_("relminmxid: advanced by %d multixact IDs, new value: %u\n"),
diff, MultiXactCutoff);
@@ -1798,6 +1805,8 @@ lazy_scan_prune(LVRelState *vacrel,
int nfrozen;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
+ TransactionId NewRelfrozenxid;
+ MultiXactId NewRelminmxid;
Assert(BufferGetBlockNumber(buf) == blkno);
@@ -1806,6 +1815,8 @@ lazy_scan_prune(LVRelState *vacrel,
retry:
/* Initialize (or reset) page-level counters */
+ NewRelfrozenxid = vacrel->NewRelfrozenxid;
+ NewRelminmxid = vacrel->NewRelminmxid;
tuples_deleted = 0;
lpdead_items = 0;
recently_dead_tuples = 0;
@@ -2015,7 +2026,9 @@ retry:
vacrel->FreezeLimit,
vacrel->MultiXactCutoff,
&frozen[nfrozen],
- &tuple_totally_frozen))
+ &tuple_totally_frozen,
+ &NewRelfrozenxid,
+ &NewRelminmxid))
{
/* Will execute freeze below */
frozen[nfrozen++].offset = offnum;
@@ -2029,13 +2042,16 @@ retry:
prunestate->all_frozen = false;
}
+ vacrel->offnum = InvalidOffsetNumber;
+
/*
* We have now divided every item on the page into either an LP_DEAD item
* that will need to be vacuumed in indexes later, or a LP_NORMAL tuple
* that remains and needs to be considered for freezing now (LP_UNUSED and
* LP_REDIRECT items also remain, but are of no further interest to us).
*/
- vacrel->offnum = InvalidOffsetNumber;
+ vacrel->NewRelfrozenxid = NewRelfrozenxid;
+ vacrel->NewRelminmxid = NewRelminmxid;
/*
* Consider the need to freeze any items with tuple storage from the page
@@ -2179,9 +2195,9 @@ retry:
* We'll always return true for a non-aggressive VACUUM, even when we know
* that this will cause them to miss out on freezing tuples from before
* vacrel->FreezeLimit cutoff -- they should never have to wait for a cleanup
- * lock. This does mean that they definitely won't be able to advance
- * relfrozenxid opportunistically (same applies to vacrel->MultiXactCutoff and
- * relminmxid). Caller waits for full cleanup lock when we return false.
+ * lock. This does mean that they will have NewRelfrozenxid ratcheting back
+ * to a known-safe value (same applies to NewRelminmxid). Caller waits for
+ * full cleanup lock when we return false.
*
* See lazy_scan_prune for an explanation of hastup return flag. The
* hasfreespace flag instructs caller on whether or not it should do generic
@@ -2205,6 +2221,8 @@ lazy_scan_noprune(LVRelState *vacrel,
missed_dead_tuples;
HeapTupleHeader tupleheader;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
+ TransactionId NewRelfrozenxid = vacrel->NewRelfrozenxid;
+ MultiXactId NewRelminmxid = vacrel->NewRelminmxid;
Assert(BufferGetBlockNumber(buf) == blkno);
@@ -2250,7 +2268,8 @@ lazy_scan_noprune(LVRelState *vacrel,
tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
if (heap_tuple_needs_freeze(tupleheader,
vacrel->FreezeLimit,
- vacrel->MultiXactCutoff, buf))
+ vacrel->MultiXactCutoff,
+ &NewRelfrozenxid, &NewRelminmxid, buf))
{
if (vacrel->aggressive)
{
@@ -2260,10 +2279,11 @@ lazy_scan_noprune(LVRelState *vacrel,
}
/*
- * Current non-aggressive VACUUM operation definitely won't be
- * able to advance relfrozenxid or relminmxid
+ * A non-aggressive VACUUM doesn't have to wait on a cleanup lock
+ * to ensure that it advances relfrozenxid to a sufficiently
+ * recent XID that happens to be present on this page. It can
+ * just accept an older New/final relfrozenxid instead.
*/
- vacrel->freeze_cutoffs_valid = false;
}
num_tuples++;
@@ -2313,6 +2333,14 @@ lazy_scan_noprune(LVRelState *vacrel,
vacrel->offnum = InvalidOffsetNumber;
+ /*
+ * We have committed to not freezing the tuples on this page (always
+ * happens with a non-aggressive VACUUM), so make sure that the target
+ * relfrozenxid/relminmxid values reflect the XIDs/MXIDs we encountered
+ */
+ vacrel->NewRelfrozenxid = NewRelfrozenxid;
+ vacrel->NewRelminmxid = NewRelminmxid;
+
/*
* Now save details of the LP_DEAD items from the page in vacrel (though
* only when VACUUM uses two-pass strategy).
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c
index 66b87347d..6bd6688ae 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/cluster.c
@@ -767,6 +767,7 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
TupleDesc oldTupDesc PG_USED_FOR_ASSERTS_ONLY;
TupleDesc newTupDesc PG_USED_FOR_ASSERTS_ONLY;
TransactionId OldestXmin;
+ MultiXactId oldestMxact;
TransactionId FreezeXid;
MultiXactId MultiXactCutoff;
bool use_sort;
@@ -856,8 +857,8 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
* Since we're going to rewrite the whole table anyway, there's no reason
* not to be aggressive about this.
*/
- vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0,
- &OldestXmin, &FreezeXid, &MultiXactCutoff);
+ vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0, &OldestXmin, &oldestMxact,
+ &FreezeXid, &MultiXactCutoff);
/*
* FreezeXid will become the table's new relfrozenxid, and that mustn't go
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 6db7b8156..cce290c78 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -943,10 +943,28 @@ get_all_vacuum_rels(int options)
* The output parameters are:
* - oldestXmin is the Xid below which tuples deleted by any xact (that
* committed) should be considered DEAD, not just RECENTLY_DEAD.
+ * - oldestMxact is the Mxid below which MultiXacts are definitely not
+ * seen as visible by any running transaction.
* - freezeLimit is the Xid below which all Xids are replaced by
* FrozenTransactionId during vacuum.
* - multiXactCutoff is the value below which all MultiXactIds are removed
* from Xmax.
+ *
+ * oldestXmin and oldestMxact can be thought of as the most recent values that
+ * can ever be passed to vac_update_relstats() as frozenxid and minmulti
+ * arguments. These exact values will be used when no newer XIDs or
+ * MultiXacts remain in the heap relation (e.g., with an empty table). It's
+ * typical for vacuumlazy.c caller to notice that older XIDs/Multixacts remain
+ * in the table, which will force it to use older value. These older final
+ * values may not be any newer than the preexisting frozenxid/minmulti values
+ * from pg_class in extreme cases. The final values are frequently fairly
+ * close to the optimal values that we give to vacuumlazy.c, though.
+ *
+ * An aggressive VACUUM always provides vac_update_relstats() arguments that
+ * are >= freezeLimit and >= multiXactCutoff. A non-aggressive VACUUM may
+ * provide arguments that are either newer or older than freezeLimit and
+ * multiXactCutoff, or non-valid values (indicating that pg_class level
+ * cutoffs cannot be advanced at all).
*/
bool
vacuum_set_xid_limits(Relation rel,
@@ -955,6 +973,7 @@ vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff)
{
@@ -963,7 +982,6 @@ vacuum_set_xid_limits(Relation rel,
int effective_multixact_freeze_max_age;
TransactionId limit;
TransactionId safeLimit;
- MultiXactId oldestMxact;
MultiXactId mxactLimit;
MultiXactId safeMxactLimit;
int freezetable;
@@ -1059,9 +1077,11 @@ vacuum_set_xid_limits(Relation rel,
effective_multixact_freeze_max_age / 2);
Assert(mxid_freezemin >= 0);
+ /* Remember for caller */
+ *oldestMxact = GetOldestMultiXactId();
+
/* compute the cutoff multi, being careful to generate a valid value */
- oldestMxact = GetOldestMultiXactId();
- mxactLimit = oldestMxact - mxid_freezemin;
+ mxactLimit = *oldestMxact - mxid_freezemin;
if (mxactLimit < FirstMultiXactId)
mxactLimit = FirstMultiXactId;
@@ -1076,8 +1096,8 @@ vacuum_set_xid_limits(Relation rel,
(errmsg("oldest multixact is far in the past"),
errhint("Close open transactions with multixacts soon to avoid wraparound problems.")));
/* Use the safe limit, unless an older mxact is still running */
- if (MultiXactIdPrecedes(oldestMxact, safeMxactLimit))
- mxactLimit = oldestMxact;
+ if (MultiXactIdPrecedes(*oldestMxact, safeMxactLimit))
+ mxactLimit = *oldestMxact;
else
mxactLimit = safeMxactLimit;
}
--
2.30.2
[application/x-patch] v4-0005-Prototype-of-opportunistic-freezing.patch (10.0K, ../../CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com/4-v4-0005-Prototype-of-opportunistic-freezing.patch)
download | inline diff:
From 919bd29902da15a5d43166dabf379cdc60d7dacb Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Mon, 13 Dec 2021 15:00:49 -0800
Subject: [PATCH v4 5/5] Prototype of opportunistic freezing.
Freeze whenever pruning modified the page, or whenever we see that we're
going to mark the page all-visible without also marking it all-frozen.
There has been plenty of discussion of opportunistic freezing in the
past. It is generally considered important as a way of minimizing
repeated dirtying of heap pages (or the total volume of FPIs in the WAL
stream) over time. While that goal is certainly very important, this
patch has another priority: making VACUUM advance relfrozenxid sooner
and more frequently.
The overall effect is that tables like pgbench's history table can be
vacuumed very frequently, and have most individual vacuum operations
generate 0 FPIs in WAL -- they will never need an aggressive VACUUM.
The old SKIP_PAGES_THRESHOLD heuristic is designed to make it more
likely that we'll be able to advance relfrozenxid, which works well when
combined with additions from earlier patches in the patch series, and
opportunistic freezing.
GUCs like vacuum_freeze_min_age never made much sense after the freeze
map work in PostgreSQL 9.6. The default is 50 million transactions,
which current tends to result in our being unable to freeze tuples
before the page is marked all-visible (but not all-frozen). This
creates a huge performance cliff later on, during the first aggressive
VACUUM. And so an important goal of opportunistic freezing is to not
allow the system to get into too much "debt" from very old unfrozen
tuples. That might actually be more important than minimizing the
absolute cost of freezing.
There is probably a small regression caused by opportunistic freezing
with workloads like pgbench, since we're freezing many more tuples than
we need to now -- while we do have fewer FPIs (even earlier on), that
may not be enough to make up for the increase in WAL records. This
problem can be addressed in a later revision, when the general picture
for this patch (especially how it affects our ability to advance
relfrozenxid early) becomes clearer.
---
src/include/access/heapam.h | 1 +
src/backend/access/heap/pruneheap.c | 8 ++-
src/backend/access/heap/vacuumlazy.c | 78 +++++++++++++++++++++++++---
3 files changed, 79 insertions(+), 8 deletions(-)
diff --git a/src/include/access/heapam.h b/src/include/access/heapam.h
index 0eb5c36a2..5e1f24e5c 100644
--- a/src/include/access/heapam.h
+++ b/src/include/access/heapam.h
@@ -188,6 +188,7 @@ extern int heap_page_prune(Relation relation, Buffer buffer,
struct GlobalVisState *vistest,
TransactionId old_snap_xmin,
TimestampTz old_snap_ts_ts,
+ bool *modified,
int *nnewlpdead,
OffsetNumber *off_loc);
extern void heap_page_prune_execute(Buffer buffer,
diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c
index 522a00af6..e95dea38d 100644
--- a/src/backend/access/heap/pruneheap.c
+++ b/src/backend/access/heap/pruneheap.c
@@ -182,11 +182,12 @@ heap_page_prune_opt(Relation relation, Buffer buffer)
*/
if (PageIsFull(page) || PageGetHeapFreeSpace(page) < minfree)
{
+ bool modified;
int ndeleted,
nnewlpdead;
ndeleted = heap_page_prune(relation, buffer, vistest, limited_xmin,
- limited_ts, &nnewlpdead, NULL);
+ limited_ts, &modified, &nnewlpdead, NULL);
/*
* Report the number of tuples reclaimed to pgstats. This is
@@ -244,6 +245,7 @@ heap_page_prune(Relation relation, Buffer buffer,
GlobalVisState *vistest,
TransactionId old_snap_xmin,
TimestampTz old_snap_ts,
+ bool *modified,
int *nnewlpdead,
OffsetNumber *off_loc)
{
@@ -375,6 +377,8 @@ heap_page_prune(Relation relation, Buffer buffer,
PageSetLSN(BufferGetPage(buffer), recptr);
}
+
+ *modified = true;
}
else
{
@@ -387,12 +391,14 @@ heap_page_prune(Relation relation, Buffer buffer,
* point in repeating the prune/defrag process until something else
* happens to the page.
*/
+ *modified = false;
if (((PageHeader) page)->pd_prune_xid != prstate.new_prune_xid ||
PageIsFull(page))
{
((PageHeader) page)->pd_prune_xid = prstate.new_prune_xid;
PageClearFull(page);
MarkBufferDirtyHint(buffer, true);
+ *modified = true;
}
}
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index c6facc9eb..a710c6cf8 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -328,6 +328,7 @@ typedef struct LVRelState
/* VACUUM operation's cutoff for pruning */
TransactionId OldestXmin;
+ MultiXactId OldestMxact;
/* VACUUM operation's cutoff for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
@@ -529,11 +530,16 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/*
* Get cutoffs that determine which tuples we need to freeze during the
- * VACUUM operation.
+ * VACUUM operation. This includes information that is used during
+ * opportunistic freezing, where the most aggressive possible cutoffs
+ * (OldestXmin and OldestMxact) are used for some heap pages, based on
+ * considerations about cost.
*
* Also determines if this is to be an aggressive VACUUM. This will
* eventually be required for any table where (for whatever reason) no
* non-aggressive VACUUM ran to completion, and advanced relfrozenxid.
+ * This used to be much more common, but we now work hard to advance
+ * relfrozenxid in non-aggressive VACUUMs.
*/
aggressive = vacuum_set_xid_limits(rel,
params->freeze_min_age,
@@ -603,6 +609,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Set cutoffs for entire VACUUM */
vacrel->OldestXmin = OldestXmin;
+ vacrel->OldestMxact = OldestMxact;
vacrel->FreezeLimit = FreezeLimit;
vacrel->MultiXactCutoff = MultiXactCutoff;
@@ -1807,6 +1814,10 @@ lazy_scan_prune(LVRelState *vacrel,
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
TransactionId NewRelfrozenxid;
MultiXactId NewRelminmxid;
+ bool modified;
+ TransactionId FreezeLimit = vacrel->FreezeLimit;
+ MultiXactId MultiXactCutoff = vacrel->MultiXactCutoff;
+ bool earlyfreezing = false;
Assert(BufferGetBlockNumber(buf) == blkno);
@@ -1833,8 +1844,19 @@ retry:
* that were deleted from indexes.
*/
tuples_deleted = heap_page_prune(rel, buf, vistest,
- InvalidTransactionId, 0, &nnewlpdead,
- &vacrel->offnum);
+ InvalidTransactionId, 0, &modified,
+ &nnewlpdead, &vacrel->offnum);
+
+ /*
+ * If page was modified during pruning, then perform early freezing
+ * opportunistically
+ */
+ if (!earlyfreezing && modified)
+ {
+ earlyfreezing = true;
+ FreezeLimit = vacrel->OldestXmin;
+ MultiXactCutoff = vacrel->OldestMxact;
+ }
/*
* Now scan the page to collect LP_DEAD items and check for tuples
@@ -1889,7 +1911,7 @@ retry:
if (ItemIdIsDead(itemid))
{
deadoffsets[lpdead_items++] = offnum;
- prunestate->all_visible = false;
+ /* Don't set all_visible to false just yet */
prunestate->has_lpdead_items = true;
continue;
}
@@ -2023,8 +2045,8 @@ retry:
if (heap_prepare_freeze_tuple(tuple.t_data,
vacrel->relfrozenxid,
vacrel->relminmxid,
- vacrel->FreezeLimit,
- vacrel->MultiXactCutoff,
+ FreezeLimit,
+ MultiXactCutoff,
&frozen[nfrozen],
&tuple_totally_frozen,
&NewRelfrozenxid,
@@ -2044,6 +2066,48 @@ retry:
vacrel->offnum = InvalidOffsetNumber;
+ /*
+ * If page is going to become all_visible (excluding any LP_DEAD items),
+ * but won't also become all_frozen (either in ongoing first heap pass, or
+ * in second heap pass after LP_DEAD items get set LP_UNUSED) then repeat
+ * our pass over the heap, using more aggressive (opportunistic) freeze
+ * limits. This policy isn't guaranteed to be cheaper in the long run,
+ * but it often is. And it makes it far more likely that non-aggressive
+ * VACUUMs will end up advancing relfrozenxid to a reasonably recent XID;
+ * an XID that we opt to freeze won't hold back NewRelfrozenxid.
+ *
+ * We deliberately track all_visible in a way that excludes LP_DEAD items
+ * here. Our assumption is that any page that is "all_visible for tuples
+ * with storage" will be safe to mark all_visible in the visibility map
+ * during VACUUM's second heap pass, right after LP_DEAD items are set
+ * LP_UNUSED. Either way (with or without LP_DEAD items), our goal is to
+ * ensure that a page that _would have_ been marked all_visible in the
+ * visibility map gets marked all_frozen instead.
+ */
+ if (!earlyfreezing && prunestate->all_visible && !prunestate->all_frozen)
+ {
+ /*
+ * XXX Need to worry about leaking MultiXacts in FreezeMultiXactId()
+ * now (via heap_prepare_freeze_tuple calls)? That was already
+ * possible, but presumably this makes it much more likely.
+ *
+ * On the other hand, that's only possible when we need to replace an
+ * existing MultiXact with a new one. Even then, we won't have
+ * preallocated a new MultiXact (which we now risk leaking) if there
+ * was only one remaining XID, and the XID is for an updater (we'll
+ * only prepare to replace xmax with the XID directly). So maybe it's
+ * still a narrow enough problem to be ignored.
+ */
+ earlyfreezing = true;
+ FreezeLimit = vacrel->OldestXmin;
+ MultiXactCutoff = vacrel->OldestMxact;
+ goto retry;
+ }
+
+ /* Time to define all_visible in a way that accounts for LP_DEAD items */
+ if (lpdead_items > 0)
+ prunestate->all_visible = false;
+
/*
* We have now divided every item on the page into either an LP_DEAD item
* that will need to be vacuumed in indexes later, or a LP_NORMAL tuple
@@ -2089,7 +2153,7 @@ retry:
{
XLogRecPtr recptr;
- recptr = log_heap_freeze(vacrel->rel, buf, vacrel->FreezeLimit,
+ recptr = log_heap_freeze(vacrel->rel, buf, FreezeLimit,
frozen, nfrozen);
PageSetLSN(page, recptr);
}
--
2.30.2
[application/x-patch] v4-0001-Simplify-lazy_scan_heap-s-handling-of-scanned-pag.patch (47.3K, ../../CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com/5-v4-0001-Simplify-lazy_scan_heap-s-handling-of-scanned-pag.patch)
download | inline diff:
From 6b4b69741461e60e66a5fcf6673ffb3e87aed1ae Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Wed, 17 Nov 2021 21:27:06 -0800
Subject: [PATCH v4 1/5] Simplify lazy_scan_heap's handling of scanned pages.
Redefine a scanned page as any heap page that actually gets pinned by
VACUUM's first pass over the heap. Pages counted by scanned_pages are
now the complement of the pages that are skipped over using the
visibility map. This new definition significantly simplifies quite a
few things.
Now heap relation truncation, visibility map bit setting, tuple counting
(e.g., for pg_class.reltuples), and tuple freezing all share a common
definition of scanned_pages. That makes it possible to remove certain
special cases, that never made much sense. We no longer need to track
tupcount_pages separately (see bugfix commit 1914c5ea for details),
since we now always count tuples from pages that are scanned_pages. We
also don't need to needlessly distinguish between aggressive and
non-aggressive VACUUM operations when we cannot immediately acquire a
cleanup lock.
Since any VACUUM (not just an aggressive VACUUM) can sometimes advance
relfrozenxid, we now make non-aggressive VACUUMs work just a little
harder in order to make that desirable outcome more likely in practice.
Aggressive VACUUMs have long checked contended pages with only a shared
lock, to avoid needlessly waiting on a cleanup lock (in the common case
where the contended page has no tuples that need to be frozen anyway).
We still don't make non-aggressive VACUUMs wait for a cleanup lock, of
course -- if we did that they'd no longer be non-aggressive. But we now
make the non-aggressive case notice that a failure to acquire a cleanup
lock on one particular heap page does not in itself make it unsafe to
advance relfrozenxid for the whole relation (which is what we usually
see in the aggressive case already).
We now also collect LP_DEAD items in the dead_items array in the case
where we cannot immediately get a cleanup lock on the buffer. We cannot
prune without a cleanup lock, but opportunistic pruning may well have
left some LP_DEAD items behind in the past -- no reason to miss those.
Only VACUUM can mark these LP_DEAD items LP_UNUSED (no opportunistic
technique is independently capable of cleaning up line pointer bloat),
so we should not squander any opportunity to do that. Commit 8523492d4e
taught VACUUM to set LP_DEAD line pointers to LP_UNUSED while only
holding an exclusive lock (not a cleanup lock), so we can expect to set
existing LP_DEAD items to LP_UNUSED reliably, even when we cannot
acquire our own cleanup lock at either pass over the heap (unless we opt
to skip index vacuuming, which implies that there is no second pass over
the heap).
We no longer report on "pin skipped pages" in log output. A later patch
will add back an improved version of the same instrumentation. We don't
want to show any information about any failures to acquire cleanup locks
unless we actually failed to do useful work as a consequence. A page
that we could not acquire a cleanup lock on is now treated as equivalent
to any other scanned page in most cases.
---
src/backend/access/heap/vacuumlazy.c | 814 +++++++++++-------
.../isolation/expected/vacuum-reltuples.out | 2 +-
.../isolation/specs/vacuum-reltuples.spec | 7 +-
3 files changed, 516 insertions(+), 307 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index db6becfed..c6d3a483f 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -152,7 +152,7 @@ typedef enum
/*
* LVDeadItems stores TIDs whose index tuples are deleted by index vacuuming.
* Each TID points to an LP_DEAD line pointer from a heap page that has been
- * processed by lazy_scan_prune.
+ * processed by lazy_scan_prune (or by lazy_scan_noprune, perhaps).
*
* Also needed by lazy_vacuum_heap_rel, which marks the same LP_DEAD line
* pointers as LP_UNUSED during second heap pass.
@@ -305,6 +305,8 @@ typedef struct LVRelState
Relation *indrels;
int nindexes;
+ /* Aggressive VACUUM (scan all unfrozen pages)? */
+ bool aggressive;
/* Wraparound failsafe has been triggered? */
bool failsafe_active;
/* Consider index vacuuming bypass optimization? */
@@ -329,6 +331,8 @@ typedef struct LVRelState
/* VACUUM operation's cutoff for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
+ /* Are FreezeLimit/MultiXactCutoff still valid? */
+ bool freeze_cutoffs_valid;
/* Error reporting state */
char *relnamespace;
@@ -343,10 +347,8 @@ typedef struct LVRelState
*/
LVDeadItems *dead_items; /* TIDs whose index tuples we'll delete */
BlockNumber rel_pages; /* total number of pages */
- BlockNumber scanned_pages; /* number of pages we examined */
- BlockNumber pinskipped_pages; /* # of pages skipped due to a pin */
- BlockNumber frozenskipped_pages; /* # of frozen pages we skipped */
- BlockNumber tupcount_pages; /* pages whose tuples we counted */
+ BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
+ BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber pages_removed; /* pages remove by truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber nonempty_pages; /* actually, last nonempty page + 1 */
@@ -359,6 +361,7 @@ typedef struct LVRelState
/* Instrumentation counters */
int num_index_scans;
+ /* Counters that follow are only for scanned_pages */
int64 tuples_deleted; /* # deleted from table */
int64 lpdead_items; /* # deleted from indexes */
int64 new_dead_tuples; /* new estimated total # of dead items in
@@ -398,19 +401,22 @@ static int elevel = -1;
/* non-export function prototypes */
-static void lazy_scan_heap(LVRelState *vacrel, VacuumParams *params,
- bool aggressive);
+static void lazy_scan_heap(LVRelState *vacrel, bool skipwithvm, int nworkers);
+static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf,
+ BlockNumber blkno, Page page,
+ bool sharelock, Buffer vmbuffer);
static void lazy_scan_prune(LVRelState *vacrel, Buffer buf,
BlockNumber blkno, Page page,
GlobalVisState *vistest,
LVPagePruneState *prunestate);
+static bool lazy_scan_noprune(LVRelState *vacrel, Buffer buf,
+ BlockNumber blkno, Page page,
+ bool *hastup, bool *hasfreespace);
static void lazy_vacuum(LVRelState *vacrel);
static bool lazy_vacuum_all_indexes(LVRelState *vacrel);
static void lazy_vacuum_heap_rel(LVRelState *vacrel);
static int lazy_vacuum_heap_page(LVRelState *vacrel, BlockNumber blkno,
Buffer buffer, int index, Buffer *vmbuffer);
-static bool lazy_check_needs_freeze(Buffer buf, bool *hastup,
- LVRelState *vacrel);
static bool lazy_check_wraparound_failsafe(LVRelState *vacrel);
static void lazy_cleanup_all_indexes(LVRelState *vacrel);
static void parallel_vacuum_process_all_indexes(LVRelState *vacrel, bool vacuum);
@@ -480,16 +486,15 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
int usecs;
double read_rate,
write_rate;
- bool aggressive; /* should we scan all unfrozen pages? */
- bool scanned_all_unfrozen; /* actually scanned all such pages? */
+ bool aggressive,
+ skipwithvm;
+ BlockNumber orig_rel_pages;
char **indnames = NULL;
TransactionId xidFullScanLimit;
MultiXactId mxactFullScanLimit;
BlockNumber new_rel_pages;
BlockNumber new_rel_allvisible;
double new_live_tuples;
- TransactionId new_frozen_xid;
- MultiXactId new_min_multi;
ErrorContextCallback errcallback;
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
@@ -535,8 +540,16 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
xidFullScanLimit);
aggressive |= MultiXactIdPrecedesOrEquals(rel->rd_rel->relminmxid,
mxactFullScanLimit);
+ skipwithvm = true;
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
+ {
+ /*
+ * Force aggressive mode, and disable skipping blocks using the
+ * visibility map (even those set all-frozen)
+ */
aggressive = true;
+ skipwithvm = false;
+ }
vacrel = (LVRelState *) palloc0(sizeof(LVRelState));
@@ -544,6 +557,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->rel = rel;
vac_open_indexes(vacrel->rel, RowExclusiveLock, &vacrel->nindexes,
&vacrel->indrels);
+ vacrel->aggressive = aggressive;
vacrel->failsafe_active = false;
vacrel->consider_bypass_optimization = true;
@@ -588,6 +602,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->OldestXmin = OldestXmin;
vacrel->FreezeLimit = FreezeLimit;
vacrel->MultiXactCutoff = MultiXactCutoff;
+ /* Track if cutoffs became invalid (possible in !aggressive case only) */
+ vacrel->freeze_cutoffs_valid = true;
vacrel->relnamespace = get_namespace_name(RelationGetNamespace(rel));
vacrel->relname = pstrdup(RelationGetRelationName(rel));
@@ -624,30 +640,16 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* Call lazy_scan_heap to perform all required heap pruning, index
* vacuuming, and heap vacuuming (plus related processing)
*/
- lazy_scan_heap(vacrel, params, aggressive);
+ lazy_scan_heap(vacrel, skipwithvm, params->nworkers);
/* Done with indexes */
vac_close_indexes(vacrel->nindexes, vacrel->indrels, NoLock);
/*
- * Compute whether we actually scanned the all unfrozen pages. If we did,
- * we can adjust relfrozenxid and relminmxid.
- *
- * NB: We need to check this before truncating the relation, because that
- * will change ->rel_pages.
- */
- if ((vacrel->scanned_pages + vacrel->frozenskipped_pages)
- < vacrel->rel_pages)
- {
- Assert(!aggressive);
- scanned_all_unfrozen = false;
- }
- else
- scanned_all_unfrozen = true;
-
- /*
- * Optionally truncate the relation.
+ * Optionally truncate the relation. But remember the relation size used
+ * by lazy_scan_prune for later first.
*/
+ orig_rel_pages = vacrel->rel_pages;
if (should_attempt_truncation(vacrel))
{
/*
@@ -678,28 +680,44 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
*
* For safety, clamp relallvisible to be not more than what we're setting
* relpages to.
- *
- * Also, don't change relfrozenxid/relminmxid if we skipped any pages,
- * since then we don't know for certain that all tuples have a newer xmin.
*/
- new_rel_pages = vacrel->rel_pages;
+ new_rel_pages = vacrel->rel_pages; /* After possible rel truncation */
new_live_tuples = vacrel->new_live_tuples;
visibilitymap_count(rel, &new_rel_allvisible, NULL);
if (new_rel_allvisible > new_rel_pages)
new_rel_allvisible = new_rel_pages;
- new_frozen_xid = scanned_all_unfrozen ? FreezeLimit : InvalidTransactionId;
- new_min_multi = scanned_all_unfrozen ? MultiXactCutoff : InvalidMultiXactId;
-
- vac_update_relstats(rel,
- new_rel_pages,
- new_live_tuples,
- new_rel_allvisible,
- vacrel->nindexes > 0,
- new_frozen_xid,
- new_min_multi,
- false);
+ /*
+ * Aggressive VACUUM must reliably advance relfrozenxid (and relminmxid).
+ * We are able to advance relfrozenxid in a non-aggressive VACUUM too,
+ * provided we didn't skip any all-visible (not all-frozen) pages using
+ * the visibility map, and assuming that we didn't fail to get a cleanup
+ * lock that made it unsafe with respect to FreezeLimit (or perhaps our
+ * MultiXactCutoff) established for VACUUM operation.
+ *
+ * NB: We must use orig_rel_pages, not vacrel->rel_pages, since we want
+ * the rel_pages used by lazy_scan_heap, which won't match when we
+ * happened to truncate the relation afterwards.
+ */
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
+ !vacrel->freeze_cutoffs_valid)
+ {
+ /* Cannot advance relfrozenxid/relminmxid -- just update pg_class */
+ Assert(!aggressive);
+ vac_update_relstats(rel, new_rel_pages, new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ InvalidTransactionId, InvalidMultiXactId, false);
+ }
+ else
+ {
+ /* Can safely advance relfrozen and relminmxid, too */
+ Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
+ orig_rel_pages);
+ vac_update_relstats(rel, new_rel_pages, new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ FreezeLimit, MultiXactCutoff, false);
+ }
/*
* Report results to the stats collector, too.
@@ -728,7 +746,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
StringInfoData buf;
char *msgfmt;
- BlockNumber orig_rel_pages;
TimestampDifference(starttime, endtime, &secs, &usecs);
@@ -775,10 +792,9 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->relnamespace,
vacrel->relname,
vacrel->num_index_scans);
- appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped due to pins, %u skipped frozen\n"),
+ appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped frozen\n"),
vacrel->pages_removed,
vacrel->rel_pages,
- vacrel->pinskipped_pages,
vacrel->frozenskipped_pages);
appendStringInfo(&buf,
_("tuples: %lld removed, %lld remain, %lld are dead but not yet removable, oldest xmin: %u\n"),
@@ -786,7 +802,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
(long long) vacrel->new_rel_tuples,
(long long) vacrel->new_dead_tuples,
OldestXmin);
- orig_rel_pages = vacrel->rel_pages + vacrel->pages_removed;
if (orig_rel_pages > 0)
{
if (vacrel->do_index_vacuuming)
@@ -903,7 +918,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* supply.
*/
static void
-lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
+lazy_scan_heap(LVRelState *vacrel, bool skipwithvm, int nworkers)
{
LVDeadItems *dead_items;
BlockNumber nblocks,
@@ -925,7 +940,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pg_rusage_init(&ru0);
- if (aggressive)
+ if (vacrel->aggressive)
ereport(elevel,
(errmsg("aggressively vacuuming \"%s.%s\"",
vacrel->relnamespace,
@@ -937,14 +952,9 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
vacrel->relname)));
nblocks = RelationGetNumberOfBlocks(vacrel->rel);
- next_unskippable_block = 0;
- next_failsafe_block = 0;
- next_fsm_block_to_vacuum = 0;
vacrel->rel_pages = nblocks;
vacrel->scanned_pages = 0;
- vacrel->pinskipped_pages = 0;
vacrel->frozenskipped_pages = 0;
- vacrel->tupcount_pages = 0;
vacrel->pages_removed = 0;
vacrel->lpdead_item_pages = 0;
vacrel->nonempty_pages = 0;
@@ -968,14 +978,16 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* dangerously old.
*/
lazy_check_wraparound_failsafe(vacrel);
+ next_failsafe_block = 0;
/*
* Allocate the space for dead_items. Note that this handles parallel
* VACUUM initialization as part of allocating shared memory space used
* for dead_items.
*/
- dead_items_alloc(vacrel, params->nworkers);
+ dead_items_alloc(vacrel, nworkers);
dead_items = vacrel->dead_items;
+ next_fsm_block_to_vacuum = 0;
/* Report that we're scanning the heap, advertising total # of blocks */
initprog_val[0] = PROGRESS_VACUUM_PHASE_SCAN_HEAP;
@@ -984,7 +996,9 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pgstat_progress_update_multi_param(3, initprog_index, initprog_val);
/*
- * Except when aggressive is set, we want to skip pages that are
+ * Set things up for skipping blocks using visibility map.
+ *
+ * Except when vacrel->aggressive is set, we want to skip pages that are
* all-visible according to the visibility map, but only when we can skip
* at least SKIP_PAGES_THRESHOLD consecutive pages. Since we're reading
* sequentially, the OS should be doing readahead for us, so there's no
@@ -993,8 +1007,8 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* page means that we can't update relfrozenxid, so we only want to do it
* if we can skip a goodly number of pages.
*
- * When aggressive is set, we can't skip pages just because they are
- * all-visible, but we can still skip pages that are all-frozen, since
+ * When vacrel->aggressive is set, we can't skip pages just because they
+ * are all-visible, but we can still skip pages that are all-frozen, since
* such pages do not need freezing and do not affect the value that we can
* safely set for relfrozenxid or relminmxid.
*
@@ -1017,17 +1031,9 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* just added to that page are necessarily newer than the GlobalXmin we
* computed, so they'll have no effect on the value to which we can safely
* set relfrozenxid. A similar argument applies for MXIDs and relminmxid.
- *
- * We will scan the table's last page, at least to the extent of
- * determining whether it has tuples or not, even if it should be skipped
- * according to the above rules; except when we've already determined that
- * it's not worth trying to truncate the table. This avoids having
- * lazy_truncate_heap() take access-exclusive lock on the table to attempt
- * a truncation that just fails immediately because there are tuples in
- * the last page. This is worth avoiding mainly because such a lock must
- * be replayed on any hot standby, where it can be disruptive.
*/
- if ((params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0)
+ next_unskippable_block = 0;
+ if (skipwithvm)
{
while (next_unskippable_block < nblocks)
{
@@ -1036,7 +1042,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
vmstatus = visibilitymap_get_status(vacrel->rel,
next_unskippable_block,
&vmbuffer);
- if (aggressive)
+ if (vacrel->aggressive)
{
if ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0)
break;
@@ -1063,13 +1069,6 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
bool all_visible_according_to_vm = false;
LVPagePruneState prunestate;
- /*
- * Consider need to skip blocks. See note above about forcing
- * scanning of last page.
- */
-#define FORCE_CHECK_PAGE() \
- (blkno == nblocks - 1 && should_attempt_truncation(vacrel))
-
pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
@@ -1079,7 +1078,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
{
/* Time to advance next_unskippable_block */
next_unskippable_block++;
- if ((params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0)
+ if (skipwithvm)
{
while (next_unskippable_block < nblocks)
{
@@ -1088,7 +1087,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
vmskipflags = visibilitymap_get_status(vacrel->rel,
next_unskippable_block,
&vmbuffer);
- if (aggressive)
+ if (vacrel->aggressive)
{
if ((vmskipflags & VISIBILITYMAP_ALL_FROZEN) == 0)
break;
@@ -1117,19 +1116,25 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* it's not all-visible. But in an aggressive vacuum we know only
* that it's not all-frozen, so it might still be all-visible.
*/
- if (aggressive && VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
+ if (vacrel->aggressive &&
+ VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
all_visible_according_to_vm = true;
}
else
{
/*
- * The current block is potentially skippable; if we've seen a
- * long enough run of skippable blocks to justify skipping it, and
- * we're not forced to check it, then go ahead and skip.
- * Otherwise, the page must be at least all-visible if not
- * all-frozen, so we can set all_visible_according_to_vm = true.
+ * The current page can be skipped if we've seen a long enough run
+ * of skippable blocks to justify skipping it -- provided it's not
+ * the last page in the relation (according to rel_pages/nblocks).
+ *
+ * We always scan the table's last page to determine whether it
+ * has tuples or not, even if it would otherwise be skipped
+ * (unless we're skipping every single page in the relation). This
+ * avoids having lazy_truncate_heap() take access-exclusive lock
+ * on the table to attempt a truncation that just fails
+ * immediately because there are tuples on the last page.
*/
- if (skipping_blocks && !FORCE_CHECK_PAGE())
+ if (skipping_blocks && blkno < nblocks - 1)
{
/*
* Tricky, tricky. If this is in aggressive vacuum, the page
@@ -1138,18 +1143,32 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
* careful to count it as a skipped all-frozen page in that
* case, or else we'll think we can't update relfrozenxid and
* relminmxid. If it's not an aggressive vacuum, we don't
- * know whether it was all-frozen, so we have to recheck; but
- * in this case an approximate answer is OK.
+ * know whether it was initially all-frozen, so we have to
+ * recheck.
*/
- if (aggressive || VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
+ if (vacrel->aggressive ||
+ VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
vacrel->frozenskipped_pages++;
continue;
}
+
+ /*
+ * Otherwise it must be an all-visible (and possibly even
+ * all-frozen) page that we decided to process regardless
+ * (SKIP_PAGES_THRESHOLD must not have been crossed).
+ */
all_visible_according_to_vm = true;
}
vacuum_delay_point();
+ /*
+ * We're not skipping this page using the visibility map, and so it is
+ * (by definition) a scanned page. Any tuples from this page are now
+ * guaranteed to be counted below, after some preparatory checks.
+ */
+ vacrel->scanned_pages++;
+
/*
* Regularly check if wraparound failsafe should trigger.
*
@@ -1204,174 +1223,78 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
}
/*
- * Set up visibility map page as needed.
- *
* Pin the visibility map page in case we need to mark the page
* all-visible. In most cases this will be very cheap, because we'll
- * already have the correct page pinned anyway. However, it's
- * possible that (a) next_unskippable_block is covered by a different
- * VM page than the current block or (b) we released our pin and did a
- * cycle of index vacuuming.
+ * already have the correct page pinned anyway.
*/
visibilitymap_pin(vacrel->rel, blkno, &vmbuffer);
+ /* Finished preparatory checks. Actually scan the page. */
buf = ReadBufferExtended(vacrel->rel, MAIN_FORKNUM, blkno,
RBM_NORMAL, vacrel->bstrategy);
+ page = BufferGetPage(buf);
/*
- * We need buffer cleanup lock so that we can prune HOT chains and
- * defragment the page.
+ * We need a buffer cleanup lock to prune HOT chains and defragment
+ * the page in lazy_scan_prune. But when it's not possible to acquire
+ * a cleanup lock right away, we may be able to settle for reduced
+ * processing using lazy_scan_noprune.
*/
if (!ConditionalLockBufferForCleanup(buf))
{
- bool hastup;
+ bool hastup,
+ hasfreespace;
- /*
- * If we're not performing an aggressive scan to guard against XID
- * wraparound, and we don't want to forcibly check the page, then
- * it's OK to skip vacuuming pages we get a lock conflict on. They
- * will be dealt with in some future vacuum.
- */
- if (!aggressive && !FORCE_CHECK_PAGE())
- {
- ReleaseBuffer(buf);
- vacrel->pinskipped_pages++;
- continue;
- }
-
- /*
- * Read the page with share lock to see if any xids on it need to
- * be frozen. If not we just skip the page, after updating our
- * scan statistics. If there are some, we wait for cleanup lock.
- *
- * We could defer the lock request further by remembering the page
- * and coming back to it later, or we could even register
- * ourselves for multiple buffers and then service whichever one
- * is received first. For now, this seems good enough.
- *
- * If we get here with aggressive false, then we're just forcibly
- * checking the page, and so we don't want to insist on getting
- * the lock; we only need to know if the page contains tuples, so
- * that we can update nonempty_pages correctly. It's convenient
- * to use lazy_check_needs_freeze() for both situations, though.
- */
LockBuffer(buf, BUFFER_LOCK_SHARE);
- if (!lazy_check_needs_freeze(buf, &hastup, vacrel))
+
+ /* Check for new or empty pages before lazy_scan_noprune call */
+ if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, true,
+ vmbuffer))
{
- UnlockReleaseBuffer(buf);
- vacrel->scanned_pages++;
- vacrel->pinskipped_pages++;
- if (hastup)
- vacrel->nonempty_pages = blkno + 1;
+ /* Processed as new/empty page (lock and pin released) */
continue;
}
- if (!aggressive)
+
+ /* Collect LP_DEAD items in dead_items array, count tuples */
+ if (lazy_scan_noprune(vacrel, buf, blkno, page, &hastup,
+ &hasfreespace))
{
+ Size freespace;
+
/*
- * Here, we must not advance scanned_pages; that would amount
- * to claiming that the page contains no freezable tuples.
+ * Processed page successfully (without cleanup lock) -- just
+ * need to perform rel truncation and FSM steps, much like the
+ * lazy_scan_prune case. Don't bother trying to match its
+ * visibility map setting steps, though.
*/
- UnlockReleaseBuffer(buf);
- vacrel->pinskipped_pages++;
if (hastup)
vacrel->nonempty_pages = blkno + 1;
+ if (hasfreespace)
+ freespace = PageGetHeapFreeSpace(page);
+ UnlockReleaseBuffer(buf);
+ if (hasfreespace)
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
continue;
}
+
+ /*
+ * lazy_scan_noprune could not do all required processing. Wait
+ * for a cleanup lock, and call lazy_scan_prune in the usual way.
+ */
+ Assert(vacrel->aggressive);
LockBuffer(buf, BUFFER_LOCK_UNLOCK);
LockBufferForCleanup(buf);
- /* drop through to normal processing */
}
- /*
- * By here we definitely have enough dead_items space for whatever
- * LP_DEAD tids are on this page, we have the visibility map page set
- * up in case we need to set this page's all_visible/all_frozen bit,
- * and we have a cleanup lock. Any tuples on this page are now sure
- * to be "counted" by this VACUUM.
- *
- * One last piece of preamble needs to take place before we can prune:
- * we need to consider new and empty pages.
- */
- vacrel->scanned_pages++;
- vacrel->tupcount_pages++;
-
- page = BufferGetPage(buf);
-
- if (PageIsNew(page))
+ /* Check for new or empty pages before lazy_scan_prune call */
+ if (lazy_scan_new_or_empty(vacrel, buf, blkno, page, false, vmbuffer))
{
- /*
- * All-zeroes pages can be left over if either a backend extends
- * the relation by a single page, but crashes before the newly
- * initialized page has been written out, or when bulk-extending
- * the relation (which creates a number of empty pages at the tail
- * end of the relation, but enters them into the FSM).
- *
- * Note we do not enter the page into the visibilitymap. That has
- * the downside that we repeatedly visit this page in subsequent
- * vacuums, but otherwise we'll never not discover the space on a
- * promoted standby. The harm of repeated checking ought to
- * normally not be too bad - the space usually should be used at
- * some point, otherwise there wouldn't be any regular vacuums.
- *
- * Make sure these pages are in the FSM, to ensure they can be
- * reused. Do that by testing if there's any space recorded for
- * the page. If not, enter it. We do so after releasing the lock
- * on the heap page, the FSM is approximate, after all.
- */
- UnlockReleaseBuffer(buf);
-
- if (GetRecordedFreeSpace(vacrel->rel, blkno) == 0)
- {
- Size freespace = BLCKSZ - SizeOfPageHeaderData;
-
- RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
- }
- continue;
- }
-
- if (PageIsEmpty(page))
- {
- Size freespace = PageGetHeapFreeSpace(page);
-
- /*
- * Empty pages are always all-visible and all-frozen (note that
- * the same is currently not true for new pages, see above).
- */
- if (!PageIsAllVisible(page))
- {
- START_CRIT_SECTION();
-
- /* mark buffer dirty before writing a WAL record */
- MarkBufferDirty(buf);
-
- /*
- * It's possible that another backend has extended the heap,
- * initialized the page, and then failed to WAL-log the page
- * due to an ERROR. Since heap extension is not WAL-logged,
- * recovery might try to replay our record setting the page
- * all-visible and find that the page isn't initialized, which
- * will cause a PANIC. To prevent that, check whether the
- * page has been previously WAL-logged, and if not, do that
- * now.
- */
- if (RelationNeedsWAL(vacrel->rel) &&
- PageGetLSN(page) == InvalidXLogRecPtr)
- log_newpage_buffer(buf, true);
-
- PageSetAllVisible(page);
- visibilitymap_set(vacrel->rel, blkno, buf, InvalidXLogRecPtr,
- vmbuffer, InvalidTransactionId,
- VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
- END_CRIT_SECTION();
- }
-
- UnlockReleaseBuffer(buf);
- RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ /* Processed as new/empty page (lock and pin released) */
continue;
}
/*
- * Prune and freeze tuples.
+ * Prune, freeze, and count tuples.
*
* Accumulates details of remaining LP_DEAD line pointers on page in
* dead_items array. This includes LP_DEAD line pointers that we
@@ -1579,7 +1502,7 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
/* now we can compute the new value for pg_class.reltuples */
vacrel->new_live_tuples = vac_estimate_reltuples(vacrel->rel, nblocks,
- vacrel->tupcount_pages,
+ vacrel->scanned_pages,
vacrel->live_tuples);
/*
@@ -1652,14 +1575,6 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
appendStringInfo(&buf,
_("%lld dead row versions cannot be removed yet, oldest xmin: %u\n"),
(long long) vacrel->new_dead_tuples, vacrel->OldestXmin);
- appendStringInfo(&buf, ngettext("Skipped %u page due to buffer pins, ",
- "Skipped %u pages due to buffer pins, ",
- vacrel->pinskipped_pages),
- vacrel->pinskipped_pages);
- appendStringInfo(&buf, ngettext("%u frozen page.\n",
- "%u frozen pages.\n",
- vacrel->frozenskipped_pages),
- vacrel->frozenskipped_pages);
appendStringInfo(&buf, _("%s."), pg_rusage_show(&ru0));
ereport(elevel,
@@ -1673,6 +1588,138 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
pfree(buf.data);
}
+/*
+ * lazy_scan_new_or_empty() -- lazy_scan_heap() new/empty page handling.
+ *
+ * Must call here to handle both new and empty pages before calling
+ * lazy_scan_prune or lazy_scan_noprune, since they're not prepared to deal
+ * with new or empty pages.
+ *
+ * It's necessary to consider new pages as a special case, since the rules for
+ * maintaining the visibility map and FSM with empty pages are a little
+ * different (though new pages can be truncated based on the usual rules).
+ *
+ * Empty pages are not really a special case -- they're just heap pages that
+ * have no allocated tuples (including even LP_UNUSED items). You might
+ * wonder why we need to handle them here all the same. It's only necessary
+ * because of a corner-case involving a hard crash during heap relation
+ * extension. If we ever make relation-extension crash safe, then it should
+ * no longer be necessary to deal with empty pages here (or new pages, for
+ * that matter).
+ *
+ * Caller must hold at least a shared lock. We might need to escalate the
+ * lock in that case, so the type of lock caller holds needs to be specified
+ * using 'sharelock' argument.
+ *
+ * Returns false in common case where caller should go on to call
+ * lazy_scan_prune (or lazy_scan_noprune). Otherwise returns true, indicating
+ * that lazy_scan_heap is done processing the page, releasing lock on caller's
+ * behalf.
+ */
+static bool
+lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf, BlockNumber blkno,
+ Page page, bool sharelock, Buffer vmbuffer)
+{
+ Size freespace;
+
+ if (PageIsNew(page))
+ {
+ /*
+ * All-zeroes pages can be left over if either a backend extends the
+ * relation by a single page, but crashes before the newly initialized
+ * page has been written out, or when bulk-extending the relation
+ * (which creates a number of empty pages at the tail end of the
+ * relation), and then enters them into the FSM.
+ *
+ * Note we do not enter the page into the visibilitymap. That has the
+ * downside that we repeatedly visit this page in subsequent vacuums,
+ * but otherwise we'll never discover the space on a promoted standby.
+ * The harm of repeated checking ought to normally not be too bad. The
+ * space usually should be used at some point, otherwise there
+ * wouldn't be any regular vacuums.
+ *
+ * Make sure these pages are in the FSM, to ensure they can be reused.
+ * Do that by testing if there's any space recorded for the page. If
+ * not, enter it. We do so after releasing the lock on the heap page,
+ * the FSM is approximate, after all.
+ */
+ UnlockReleaseBuffer(buf);
+
+ if (GetRecordedFreeSpace(vacrel->rel, blkno) == 0)
+ {
+ freespace = BLCKSZ - SizeOfPageHeaderData;
+
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ }
+
+ return true;
+ }
+
+ if (PageIsEmpty(page))
+ {
+ /*
+ * It seems likely that caller will always be able to get a cleanup
+ * lock on an empty page. But don't take any chances -- escalate to
+ * an exclusive lock (still don't need a cleanup lock, though).
+ */
+ if (sharelock)
+ {
+ LockBuffer(buf, BUFFER_LOCK_UNLOCK);
+ LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
+
+ if (!PageIsEmpty(page))
+ {
+ /* page isn't new or empty -- keep lock and pin for now */
+ return false;
+ }
+ }
+ else
+ {
+ /* Already have a full cleanup lock (which is more than enough) */
+ }
+
+ freespace = PageGetHeapFreeSpace(page);
+
+ /*
+ * Unlike new pages, empty pages are always set all-visible and
+ * all-frozen.
+ */
+ if (!PageIsAllVisible(page))
+ {
+ START_CRIT_SECTION();
+
+ /* mark buffer dirty before writing a WAL record */
+ MarkBufferDirty(buf);
+
+ /*
+ * It's possible that another backend has extended the heap,
+ * initialized the page, and then failed to WAL-log the page due
+ * to an ERROR. Since heap extension is not WAL-logged, recovery
+ * might try to replay our record setting the page all-visible and
+ * find that the page isn't initialized, which will cause a PANIC.
+ * To prevent that, check whether the page has been previously
+ * WAL-logged, and if not, do that now.
+ */
+ if (RelationNeedsWAL(vacrel->rel) &&
+ PageGetLSN(page) == InvalidXLogRecPtr)
+ log_newpage_buffer(buf, true);
+
+ PageSetAllVisible(page);
+ visibilitymap_set(vacrel->rel, blkno, buf, InvalidXLogRecPtr,
+ vmbuffer, InvalidTransactionId,
+ VISIBILITYMAP_ALL_VISIBLE | VISIBILITYMAP_ALL_FROZEN);
+ END_CRIT_SECTION();
+ }
+
+ UnlockReleaseBuffer(buf);
+ RecordPageWithFreeSpace(vacrel->rel, blkno, freespace);
+ return true;
+ }
+
+ /* page isn't new or empty -- keep lock and pin */
+ return false;
+}
+
/*
* lazy_scan_prune() -- lazy_scan_heap() pruning and freezing.
*
@@ -1717,6 +1764,8 @@ lazy_scan_prune(LVRelState *vacrel,
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
+ Assert(BufferGetBlockNumber(buf) == blkno);
+
maxoff = PageGetMaxOffsetNumber(page);
retry:
@@ -1779,10 +1828,9 @@ retry:
* LP_DEAD items are processed outside of the loop.
*
* Note that we deliberately don't set hastup=true in the case of an
- * LP_DEAD item here, which is not how lazy_check_needs_freeze() or
- * count_nondeletable_pages() do it -- they only consider pages empty
- * when they only have LP_UNUSED items, which is important for
- * correctness.
+ * LP_DEAD item here, which is not how count_nondeletable_pages() does
+ * it -- it only considers pages empty/truncatable when they have no
+ * items at all (except LP_UNUSED items).
*
* Our assumption is that any LP_DEAD items we encounter here will
* become LP_UNUSED inside lazy_vacuum_heap_page() before we actually
@@ -2069,6 +2117,225 @@ retry:
vacrel->live_tuples += live_tuples;
}
+/*
+ * lazy_scan_noprune() -- lazy_scan_prune() variant without pruning
+ *
+ * Caller need only hold a pin and share lock on the buffer, unlike
+ * lazy_scan_prune, which requires a full cleanup lock.
+ *
+ * While pruning isn't performed here, we can at least collect existing
+ * LP_DEAD items into the dead_items array for removal from indexes. It's
+ * quite possible that earlier opportunistic pruning left LP_DEAD items
+ * behind, and we shouldn't miss out on an opportunity to make them reusable
+ * (VACUUM alone is capable of cleaning up line pointer bloat like this).
+ * Note that we'll only require an exclusive lock (not a cleanup lock) later
+ * on when we set these LP_DEAD items to LP_UNUSED in lazy_vacuum_heap_page.
+ *
+ * Freezing isn't performed here either. For aggressive VACUUM callers, we
+ * may return false to indicate that a full cleanup lock is required. This is
+ * necessary because pruning requires a cleanup lock, and because VACUUM
+ * cannot freeze a page's tuples until after pruning takes place (freezing
+ * tuples effectively requires a cleanup lock, though we don't need a cleanup
+ * lock in lazy_vacuum_heap_page or in lazy_scan_new_or_empty to set a heap
+ * page all-frozen in the visibility map).
+ *
+ * Returns true to indicate that all required processing has been performed.
+ * We'll always return true for a non-aggressive VACUUM, even when we know
+ * that this will cause them to miss out on freezing tuples from before
+ * vacrel->FreezeLimit cutoff -- they should never have to wait for a cleanup
+ * lock. This does mean that they definitely won't be able to advance
+ * relfrozenxid opportunistically (same applies to vacrel->MultiXactCutoff and
+ * relminmxid). Caller waits for full cleanup lock when we return false.
+ *
+ * See lazy_scan_prune for an explanation of hastup return flag. The
+ * hasfreespace flag instructs caller on whether or not it should do generic
+ * FSM processing for page, which is determined based on almost the same
+ * criteria as the lazy_scan_prune case.
+ */
+static bool
+lazy_scan_noprune(LVRelState *vacrel,
+ Buffer buf,
+ BlockNumber blkno,
+ Page page,
+ bool *hastup,
+ bool *hasfreespace)
+{
+ OffsetNumber offnum,
+ maxoff;
+ int lpdead_items,
+ num_tuples,
+ live_tuples,
+ new_dead_tuples;
+ HeapTupleHeader tupleheader;
+ OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
+
+ Assert(BufferGetBlockNumber(buf) == blkno);
+
+ *hastup = false; /* for now */
+ *hasfreespace = false; /* for now */
+
+ lpdead_items = 0;
+ num_tuples = 0;
+ live_tuples = 0;
+ new_dead_tuples = 0;
+
+ maxoff = PageGetMaxOffsetNumber(page);
+ for (offnum = FirstOffsetNumber;
+ offnum <= maxoff;
+ offnum = OffsetNumberNext(offnum))
+ {
+ ItemId itemid;
+ HeapTupleData tuple;
+
+ vacrel->offnum = offnum;
+ itemid = PageGetItemId(page, offnum);
+
+ if (!ItemIdIsUsed(itemid))
+ continue;
+
+ if (ItemIdIsRedirected(itemid))
+ {
+ *hastup = true; /* page prevents rel truncation */
+ continue;
+ }
+
+ if (ItemIdIsDead(itemid))
+ {
+ /*
+ * Deliberately don't set hastup=true here. See same point in
+ * lazy_scan_prune for an explanation.
+ */
+ deadoffsets[lpdead_items++] = offnum;
+ continue;
+ }
+
+ tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
+ if (heap_tuple_needs_freeze(tupleheader,
+ vacrel->FreezeLimit,
+ vacrel->MultiXactCutoff, buf))
+ {
+ if (vacrel->aggressive)
+ {
+ /* Going to have to get cleanup lock for lazy_scan_prune */
+ vacrel->offnum = InvalidOffsetNumber;
+ return false;
+ }
+
+ /*
+ * Current non-aggressive VACUUM operation definitely won't be
+ * able to advance relfrozenxid or relminmxid
+ */
+ vacrel->freeze_cutoffs_valid = false;
+ }
+
+ num_tuples++;
+ ItemPointerSet(&(tuple.t_self), blkno, offnum);
+ tuple.t_data = (HeapTupleHeader) PageGetItem(page, itemid);
+ tuple.t_len = ItemIdGetLength(itemid);
+ tuple.t_tableOid = RelationGetRelid(vacrel->rel);
+
+ switch (HeapTupleSatisfiesVacuum(&tuple, vacrel->OldestXmin, buf))
+ {
+ case HEAPTUPLE_DELETE_IN_PROGRESS:
+ case HEAPTUPLE_LIVE:
+
+ /*
+ * Count both cases as live, just like lazy_scan_prune
+ */
+ live_tuples++;
+
+ break;
+ case HEAPTUPLE_DEAD:
+
+ /*
+ * There is some useful work for pruning to do, that won't be
+ * done due to failure to get a cleanup lock.
+ *
+ * TODO Add dedicated instrumentation for this case
+ */
+ break;
+ case HEAPTUPLE_RECENTLY_DEAD:
+
+ /*
+ * Count in new_dead_tuples, just like lazy_scan_prune
+ */
+ new_dead_tuples++;
+ break;
+ case HEAPTUPLE_INSERT_IN_PROGRESS:
+
+ /*
+ * Do not count these rows as live, just like lazy_scan_prune
+ */
+ break;
+ default:
+ elog(ERROR, "unexpected HeapTupleSatisfiesVacuum result");
+ break;
+ }
+
+ }
+
+ vacrel->offnum = InvalidOffsetNumber;
+
+ /*
+ * Now save details of the LP_DEAD items from the page in vacrel (though
+ * only when VACUUM uses two-pass strategy).
+ */
+ if (vacrel->nindexes == 0)
+ {
+ /*
+ * Using one-pass strategy.
+ *
+ * We are not prepared to handle the corner case where a single pass
+ * strategy VACUUM cannot get a cleanup lock, and we then find LP_DEAD
+ * items.
+ */
+ if (lpdead_items > 0)
+ *hastup = true;
+ *hasfreespace = true;
+ num_tuples += lpdead_items;
+ /* TODO HEAPTUPLE_DEAD style instrumentation needed here, too */
+ }
+ else if (lpdead_items > 0)
+ {
+ LVDeadItems *dead_items = vacrel->dead_items;
+ ItemPointerData tmp;
+
+ vacrel->lpdead_item_pages++;
+
+ ItemPointerSetBlockNumber(&tmp, blkno);
+
+ for (int i = 0; i < lpdead_items; i++)
+ {
+ ItemPointerSetOffsetNumber(&tmp, deadoffsets[i]);
+ dead_items->items[dead_items->num_items++] = tmp;
+ }
+
+ Assert(dead_items->num_items <= dead_items->max_items);
+ pgstat_progress_update_param(PROGRESS_VACUUM_NUM_DEAD_TUPLES,
+ dead_items->num_items);
+
+ vacrel->lpdead_items += lpdead_items;
+ }
+ else
+ {
+ /*
+ * Caller won't be vacuuming this page later, so tell it to record
+ * page's freespace in the FSM now
+ */
+ *hasfreespace = true;
+ }
+
+ /*
+ * Finally, add relevant page-local counts to whole-VACUUM counts
+ */
+ vacrel->new_dead_tuples += new_dead_tuples;
+ vacrel->num_tuples += num_tuples;
+ vacrel->live_tuples += live_tuples;
+
+ /* Caller won't need to call lazy_scan_prune with same page */
+ return true;
+}
+
/*
* Remove the collected garbage tuples from the table and its indexes.
*
@@ -2515,67 +2782,6 @@ lazy_vacuum_heap_page(LVRelState *vacrel, BlockNumber blkno, Buffer buffer,
return index;
}
-/*
- * lazy_check_needs_freeze() -- scan page to see if any tuples
- * need to be cleaned to avoid wraparound
- *
- * Returns true if the page needs to be vacuumed using cleanup lock.
- * Also returns a flag indicating whether page contains any tuples at all.
- */
-static bool
-lazy_check_needs_freeze(Buffer buf, bool *hastup, LVRelState *vacrel)
-{
- Page page = BufferGetPage(buf);
- OffsetNumber offnum,
- maxoff;
- HeapTupleHeader tupleheader;
-
- *hastup = false;
-
- /*
- * New and empty pages, obviously, don't contain tuples. We could make
- * sure that the page is registered in the FSM, but it doesn't seem worth
- * waiting for a cleanup lock just for that, especially because it's
- * likely that the pin holder will do so.
- */
- if (PageIsNew(page) || PageIsEmpty(page))
- return false;
-
- maxoff = PageGetMaxOffsetNumber(page);
- for (offnum = FirstOffsetNumber;
- offnum <= maxoff;
- offnum = OffsetNumberNext(offnum))
- {
- ItemId itemid;
-
- /*
- * Set the offset number so that we can display it along with any
- * error that occurred while processing this tuple.
- */
- vacrel->offnum = offnum;
- itemid = PageGetItemId(page, offnum);
-
- /* this should match hastup test in count_nondeletable_pages() */
- if (ItemIdIsUsed(itemid))
- *hastup = true;
-
- /* dead and redirect items never need freezing */
- if (!ItemIdIsNormal(itemid))
- continue;
-
- tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
-
- if (heap_tuple_needs_freeze(tupleheader, vacrel->FreezeLimit,
- vacrel->MultiXactCutoff, buf))
- break;
- } /* scan along page */
-
- /* Clear the offset information once we have processed the given page. */
- vacrel->offnum = InvalidOffsetNumber;
-
- return (offnum <= maxoff);
-}
-
/*
* Trigger the failsafe to avoid wraparound failure when vacrel table has a
* relfrozenxid and/or relminmxid that is dangerously far in the past.
@@ -2663,7 +2869,7 @@ parallel_vacuum_process_all_indexes(LVRelState *vacrel, bool vacuum)
*/
vacrel->lps->lvshared->reltuples = vacrel->new_rel_tuples;
vacrel->lps->lvshared->estimated_count =
- (vacrel->tupcount_pages < vacrel->rel_pages);
+ (vacrel->scanned_pages < vacrel->rel_pages);
new_status = PARALLEL_INDVAC_STATUS_NEED_CLEANUP;
@@ -2982,7 +3188,7 @@ lazy_cleanup_all_indexes(LVRelState *vacrel)
{
double reltuples = vacrel->new_rel_tuples;
bool estimated_count =
- vacrel->tupcount_pages < vacrel->rel_pages;
+ vacrel->scanned_pages < vacrel->rel_pages;
for (int idx = 0; idx < vacrel->nindexes; idx++)
{
@@ -3133,7 +3339,9 @@ lazy_cleanup_one_index(Relation indrel, IndexBulkDeleteResult *istat,
* should_attempt_truncation - should we attempt to truncate the heap?
*
* Don't even think about it unless we have a shot at releasing a goodly
- * number of pages. Otherwise, the time taken isn't worth it.
+ * number of pages. Otherwise, the time taken isn't worth it, mainly because
+ * an AccessExclusive lock must be replayed on any hot standby, where it can
+ * be particularly disruptive.
*
* Also don't attempt it if wraparound failsafe is in effect. It's hard to
* predict how long lazy_truncate_heap will take. Don't take any chances.
diff --git a/src/test/isolation/expected/vacuum-reltuples.out b/src/test/isolation/expected/vacuum-reltuples.out
index cdbe7f3a6..ce55376e7 100644
--- a/src/test/isolation/expected/vacuum-reltuples.out
+++ b/src/test/isolation/expected/vacuum-reltuples.out
@@ -45,7 +45,7 @@ step stats:
relpages|reltuples
--------+---------
- 1| 20
+ 1| 21
(1 row)
diff --git a/src/test/isolation/specs/vacuum-reltuples.spec b/src/test/isolation/specs/vacuum-reltuples.spec
index ae2f79b8f..a2a461f2f 100644
--- a/src/test/isolation/specs/vacuum-reltuples.spec
+++ b/src/test/isolation/specs/vacuum-reltuples.spec
@@ -2,9 +2,10 @@
# to page pins. We absolutely need to avoid setting reltuples=0 in
# such cases, since that interferes badly with planning.
#
-# Expected result in second permutation is 20 tuples rather than 21 as
-# for the others, because vacuum should leave the previous result
-# (from before the insert) in place.
+# Expected result for all three permutation is 21 tuples, including
+# the second permutation. VACUUM is able to count the concurrently
+# inserted tuple in its final reltuples, even when a cleanup lock
+# cannot be acquired on the affected heap page.
setup {
create table smalltbl
--
2.30.2
[application/x-patch] v4-0003-Simplify-vacuum_set_xid_limits-signature.patch (10.8K, ../../CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com/6-v4-0003-Simplify-vacuum_set_xid_limits-signature.patch)
download | inline diff:
From 09dff0737d045713cc536c736b8b05b578bfdb9d Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Sat, 11 Dec 2021 17:39:45 -0800
Subject: [PATCH v4 3/5] Simplify vacuum_set_xid_limits signature.
Refactoring, making the return value of vacuum_set_xid_limits()
determine whether or not this will be an aggressive VACUUM.
This will make it easier to set/return an oldestMxact value for
vacuumlazy.c caller in the next commit, which is an important detail
that enables advancing relminmxid opportunistically.
---
src/include/commands/vacuum.h | 6 +-
src/backend/access/heap/vacuumlazy.c | 32 +++----
src/backend/commands/cluster.c | 3 +-
src/backend/commands/vacuum.c | 134 +++++++++++++--------------
4 files changed, 79 insertions(+), 96 deletions(-)
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index bc625463e..6eefe8129 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -266,15 +266,13 @@ extern void vac_update_relstats(Relation relation,
bool *frozenxid_updated,
bool *minmulti_updated,
bool in_outer_xact);
-extern void vacuum_set_xid_limits(Relation rel,
+extern bool vacuum_set_xid_limits(Relation rel,
int freeze_min_age, int freeze_table_age,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
TransactionId *freezeLimit,
- TransactionId *xidFullScanLimit,
- MultiXactId *multiXactCutoff,
- MultiXactId *mxactFullScanLimit);
+ MultiXactId *multiXactCutoff);
extern bool vacuum_xid_failsafe_check(TransactionId relfrozenxid,
MultiXactId relminmxid);
extern void vac_update_datfrozenxid(void);
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 238e07a78..da5b3f79a 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -494,8 +494,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
minmulti_updated;
BlockNumber orig_rel_pages;
char **indnames = NULL;
- TransactionId xidFullScanLimit;
- MultiXactId mxactFullScanLimit;
BlockNumber new_rel_pages;
BlockNumber new_rel_allvisible;
double new_live_tuples;
@@ -526,24 +524,22 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
pgstat_progress_start_command(PROGRESS_COMMAND_VACUUM,
RelationGetRelid(rel));
- vacuum_set_xid_limits(rel,
- params->freeze_min_age,
- params->freeze_table_age,
- params->multixact_freeze_min_age,
- params->multixact_freeze_table_age,
- &OldestXmin, &FreezeLimit, &xidFullScanLimit,
- &MultiXactCutoff, &mxactFullScanLimit);
-
/*
- * We request an aggressive scan if the table's frozen Xid is now older
- * than or equal to the requested Xid full-table scan limit; or if the
- * table's minimum MultiXactId is older than or equal to the requested
- * mxid full-table scan limit; or if DISABLE_PAGE_SKIPPING was specified.
+ * Get cutoffs that determine which tuples we need to freeze during the
+ * VACUUM operation.
+ *
+ * Also determines if this is to be an aggressive VACUUM. This will
+ * eventually be required for any table where (for whatever reason) no
+ * non-aggressive VACUUM ran to completion, and advanced relfrozenxid.
*/
- aggressive = TransactionIdPrecedesOrEquals(rel->rd_rel->relfrozenxid,
- xidFullScanLimit);
- aggressive |= MultiXactIdPrecedesOrEquals(rel->rd_rel->relminmxid,
- mxactFullScanLimit);
+ aggressive = vacuum_set_xid_limits(rel,
+ params->freeze_min_age,
+ params->freeze_table_age,
+ params->multixact_freeze_min_age,
+ params->multixact_freeze_table_age,
+ &OldestXmin, &FreezeLimit,
+ &MultiXactCutoff);
+
skipwithvm = true;
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
{
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c
index 9d22f648a..66b87347d 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/cluster.c
@@ -857,8 +857,7 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
* not to be aggressive about this.
*/
vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0,
- &OldestXmin, &FreezeXid, NULL, &MultiXactCutoff,
- NULL);
+ &OldestXmin, &FreezeXid, &MultiXactCutoff);
/*
* FreezeXid will become the table's new relfrozenxid, and that mustn't go
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 8bd4bd12c..6db7b8156 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -935,25 +935,20 @@ get_all_vacuum_rels(int options)
*
* Input parameters are the target relation, applicable freeze age settings.
*
+ * Return value indicates whether caller should do an aggressive VACUUM or
+ * not. This is a VACUUM that cannot skip any pages using the visibility map
+ * (except all-frozen pages), which is guaranteed to be able to advance
+ * relfrozenxid and relminmxid.
+ *
* The output parameters are:
- * - oldestXmin is the cutoff value used to distinguish whether tuples are
- * DEAD or RECENTLY_DEAD (see HeapTupleSatisfiesVacuum).
+ * - oldestXmin is the Xid below which tuples deleted by any xact (that
+ * committed) should be considered DEAD, not just RECENTLY_DEAD.
* - freezeLimit is the Xid below which all Xids are replaced by
* FrozenTransactionId during vacuum.
- * - xidFullScanLimit (computed from freeze_table_age parameter)
- * represents a minimum Xid value; a table whose relfrozenxid is older than
- * this will have a full-table vacuum applied to it, to freeze tuples across
- * the whole table. Vacuuming a table younger than this value can use a
- * partial scan.
- * - multiXactCutoff is the value below which all MultiXactIds are removed from
- * Xmax.
- * - mxactFullScanLimit is a value against which a table's relminmxid value is
- * compared to produce a full-table vacuum, as with xidFullScanLimit.
- *
- * xidFullScanLimit and mxactFullScanLimit can be passed as NULL if caller is
- * not interested.
+ * - multiXactCutoff is the value below which all MultiXactIds are removed
+ * from Xmax.
*/
-void
+bool
vacuum_set_xid_limits(Relation rel,
int freeze_min_age,
int freeze_table_age,
@@ -961,9 +956,7 @@ vacuum_set_xid_limits(Relation rel,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
TransactionId *freezeLimit,
- TransactionId *xidFullScanLimit,
- MultiXactId *multiXactCutoff,
- MultiXactId *mxactFullScanLimit)
+ MultiXactId *multiXactCutoff)
{
int freezemin;
int mxid_freezemin;
@@ -973,6 +966,7 @@ vacuum_set_xid_limits(Relation rel,
MultiXactId oldestMxact;
MultiXactId mxactLimit;
MultiXactId safeMxactLimit;
+ int freezetable;
/*
* We can always ignore processes running lazy vacuum. This is because we
@@ -1090,64 +1084,60 @@ vacuum_set_xid_limits(Relation rel,
*multiXactCutoff = mxactLimit;
- if (xidFullScanLimit != NULL)
- {
- int freezetable;
+ /*
+ * Done setting output parameters; just need to figure out if caller needs
+ * to do an aggressive VACUUM or not.
+ *
+ * Determine the table freeze age to use: as specified by the caller, or
+ * vacuum_freeze_table_age, but in any case not more than
+ * autovacuum_freeze_max_age * 0.95, so that if you have e.g nightly
+ * VACUUM schedule, the nightly VACUUM gets a chance to freeze tuples
+ * before anti-wraparound autovacuum is launched.
+ */
+ freezetable = freeze_table_age;
+ if (freezetable < 0)
+ freezetable = vacuum_freeze_table_age;
+ freezetable = Min(freezetable, autovacuum_freeze_max_age * 0.95);
+ Assert(freezetable >= 0);
- Assert(mxactFullScanLimit != NULL);
+ /*
+ * Compute XID limit causing an aggressive vacuum, being careful not to
+ * generate a "permanent" XID
+ */
+ limit = ReadNextTransactionId() - freezetable;
+ if (!TransactionIdIsNormal(limit))
+ limit = FirstNormalTransactionId;
+ if (TransactionIdPrecedesOrEquals(rel->rd_rel->relfrozenxid,
+ limit))
+ return true;
- /*
- * Determine the table freeze age to use: as specified by the caller,
- * or vacuum_freeze_table_age, but in any case not more than
- * autovacuum_freeze_max_age * 0.95, so that if you have e.g nightly
- * VACUUM schedule, the nightly VACUUM gets a chance to freeze tuples
- * before anti-wraparound autovacuum is launched.
- */
- freezetable = freeze_table_age;
- if (freezetable < 0)
- freezetable = vacuum_freeze_table_age;
- freezetable = Min(freezetable, autovacuum_freeze_max_age * 0.95);
- Assert(freezetable >= 0);
+ /*
+ * Similar to the above, determine the table freeze age to use for
+ * multixacts: as specified by the caller, or
+ * vacuum_multixact_freeze_table_age, but in any case not more than
+ * autovacuum_multixact_freeze_table_age * 0.95, so that if you have e.g.
+ * nightly VACUUM schedule, the nightly VACUUM gets a chance to freeze
+ * multixacts before anti-wraparound autovacuum is launched.
+ */
+ freezetable = multixact_freeze_table_age;
+ if (freezetable < 0)
+ freezetable = vacuum_multixact_freeze_table_age;
+ freezetable = Min(freezetable,
+ effective_multixact_freeze_max_age * 0.95);
+ Assert(freezetable >= 0);
- /*
- * Compute XID limit causing a full-table vacuum, being careful not to
- * generate a "permanent" XID.
- */
- limit = ReadNextTransactionId() - freezetable;
- if (!TransactionIdIsNormal(limit))
- limit = FirstNormalTransactionId;
+ /*
+ * Compute MultiXact limit causing an aggressive vacuum, being careful to
+ * generate a valid MultiXact value
+ */
+ mxactLimit = ReadNextMultiXactId() - freezetable;
+ if (mxactLimit < FirstMultiXactId)
+ mxactLimit = FirstMultiXactId;
+ if (MultiXactIdPrecedesOrEquals(rel->rd_rel->relminmxid,
+ mxactLimit))
+ return true;
- *xidFullScanLimit = limit;
-
- /*
- * Similar to the above, determine the table freeze age to use for
- * multixacts: as specified by the caller, or
- * vacuum_multixact_freeze_table_age, but in any case not more than
- * autovacuum_multixact_freeze_table_age * 0.95, so that if you have
- * e.g. nightly VACUUM schedule, the nightly VACUUM gets a chance to
- * freeze multixacts before anti-wraparound autovacuum is launched.
- */
- freezetable = multixact_freeze_table_age;
- if (freezetable < 0)
- freezetable = vacuum_multixact_freeze_table_age;
- freezetable = Min(freezetable,
- effective_multixact_freeze_max_age * 0.95);
- Assert(freezetable >= 0);
-
- /*
- * Compute MultiXact limit causing a full-table vacuum, being careful
- * to generate a valid MultiXact value.
- */
- mxactLimit = ReadNextMultiXactId() - freezetable;
- if (mxactLimit < FirstMultiXactId)
- mxactLimit = FirstMultiXactId;
-
- *mxactFullScanLimit = mxactLimit;
- }
- else
- {
- Assert(mxactFullScanLimit == NULL);
- }
+ return false;
}
/*
--
2.30.2
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-12-17 06:46 Masahiko Sawada <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Masahiko Sawada @ 2021-12-17 06:46 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Andres Freund <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Dec 16, 2021 at 5:27 AM Peter Geoghegan <[email protected]> wrote:
>
> On Fri, Dec 10, 2021 at 1:48 PM Peter Geoghegan <[email protected]> wrote:
> > * I'm still working on the optimization that we discussed on this
> > thread: the optimization that allows the final relfrozenxid (that we
> > set in pg_class) to be determined dynamically, based on the actual
> > XIDs we observed in the table (we don't just naively use FreezeLimit).
>
> Attached is v4 of the patch series, which now includes this
> optimization, broken out into its own patch. In addition, it includes
> a prototype of opportunistic freezing.
>
> My emphasis here has been on making non-aggressive VACUUMs *always*
> advance relfrozenxid, outside of certain obvious edge cases. And so
> with all the patches applied, up to and including the opportunistic
> freezing patch, every autovacuum of every table manages to advance
> relfrozenxid during benchmarking -- usually to a fairly recent value.
> I've focussed on making aggressive VACUUMs (especially anti-wraparound
> autovacuums) a rare occurrence, for truly exceptional cases (e.g.,
> user keeps canceling autovacuums, maybe due to automated script that
> performs DDL). That has taken priority over other goals, for now.
Great!
I've looked at 0001 patch and here are some comments:
@@ -535,8 +540,16 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
xidFullScanLimit);
aggressive |= MultiXactIdPrecedesOrEquals(rel->rd_rel->relminmxid,
mxactFullScanLimit);
+ skipwithvm = true;
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
+ {
+ /*
+ * Force aggressive mode, and disable skipping blocks using the
+ * visibility map (even those set all-frozen)
+ */
aggressive = true;
+ skipwithvm = false;
+ }
vacrel = (LVRelState *) palloc0(sizeof(LVRelState));
@@ -544,6 +557,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->rel = rel;
vac_open_indexes(vacrel->rel, RowExclusiveLock, &vacrel->nindexes,
&vacrel->indrels);
+ vacrel->aggressive = aggressive;
vacrel->failsafe_active = false;
vacrel->consider_bypass_optimization = true;
How about adding skipwithvm to LVRelState too?
---
/*
- * The current block is potentially skippable;
if we've seen a
- * long enough run of skippable blocks to
justify skipping it, and
- * we're not forced to check it, then go ahead and skip.
- * Otherwise, the page must be at least
all-visible if not
- * all-frozen, so we can set
all_visible_according_to_vm = true.
+ * The current page can be skipped if we've
seen a long enough run
+ * of skippable blocks to justify skipping it
-- provided it's not
+ * the last page in the relation (according to
rel_pages/nblocks).
+ *
+ * We always scan the table's last page to
determine whether it
+ * has tuples or not, even if it would
otherwise be skipped
+ * (unless we're skipping every single page in
the relation). This
+ * avoids having lazy_truncate_heap() take
access-exclusive lock
+ * on the table to attempt a truncation that just fails
+ * immediately because there are tuples on the
last page.
*/
- if (skipping_blocks && !FORCE_CHECK_PAGE())
+ if (skipping_blocks && blkno < nblocks - 1)
Why do we always need to scan the last page even if heap truncation is
disabled (or in the failsafe mode)?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-12-18 02:29 Peter Geoghegan <[email protected]>
parent: Masahiko Sawada <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2021-12-18 02:29 UTC (permalink / raw)
To: Masahiko Sawada <[email protected]>; +Cc: Andres Freund <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Dec 16, 2021 at 10:46 PM Masahiko Sawada <[email protected]> wrote:
> > My emphasis here has been on making non-aggressive VACUUMs *always*
> > advance relfrozenxid, outside of certain obvious edge cases. And so
> > with all the patches applied, up to and including the opportunistic
> > freezing patch, every autovacuum of every table manages to advance
> > relfrozenxid during benchmarking -- usually to a fairly recent value.
> > I've focussed on making aggressive VACUUMs (especially anti-wraparound
> > autovacuums) a rare occurrence, for truly exceptional cases (e.g.,
> > user keeps canceling autovacuums, maybe due to automated script that
> > performs DDL). That has taken priority over other goals, for now.
>
> Great!
Maybe this is a good time to revisit basic questions about VACUUM. I
wonder if we can get rid of some of the GUCs for VACUUM now.
Can we fully get rid of vacuum_freeze_table_age? Maybe even get rid of
vacuum_freeze_min_age, too? Freezing tuples is a maintenance task for
physical blocks, but we use logical units (XIDs).
We probably shouldn't be using any units, but using XIDs "feels wrong"
to me. Even with my patch, it is theoretically possible that we won't
be able to advance relfrozenxid very much, because we cannot get a
cleanup lock on one single heap page with one old XID. But even in
this extreme case, how relevant is the "age" of this old XID, really?
What really matters is whether or not we can advance relfrozenxid in
time (with time to spare). And so the wraparound risk of the system is
not affected all that much by the age of the single oldest XID. The
risk mostly comes from how much total work we still need to do to
advance relfrozenxid. If the single old XID is quite old indeed (~1.5
billion XIDs), but there is only one, then we just have to freeze one
tuple to be able to safely advance relfrozenxid (maybe advance it by a
huge amount!). How long can it take to freeze one tuple, with the
freeze map, etc?
On the other hand, the risk may be far greater if we have *many*
tuples that are still unfrozen, whose XIDs are only "middle aged"
right now. The idea behind vacuum_freeze_min_age seems to be to be
lazy about work (tuple freezing) in the hope that we'll never need to
do it, but that seems obsolete now. (It probably made a little more
sense before the visibility map.)
Using XIDs makes sense for things like autovacuum_freeze_max_age,
because there we have to worry about wraparound and relfrozenxid
(whether or not we like it). But with this patch, and with everything
else (the failsafe, insert-driven autovacuums, everything we've done
over the last several years) I think that it might be time to increase
the autovacuum_freeze_max_age default. Maybe even to something as high
as 800 million transaction IDs, but certainly to 400 million. What do
you think? (Maybe don't answer just yet, something to think about.)
> + vacrel->aggressive = aggressive;
> vacrel->failsafe_active = false;
> vacrel->consider_bypass_optimization = true;
>
> How about adding skipwithvm to LVRelState too?
Agreed -- it's slightly better that way. Will change this.
> */
> - if (skipping_blocks && !FORCE_CHECK_PAGE())
> + if (skipping_blocks && blkno < nblocks - 1)
>
> Why do we always need to scan the last page even if heap truncation is
> disabled (or in the failsafe mode)?
My goal here was to keep the behavior from commit e8429082, "Avoid
useless truncation attempts during VACUUM", while simplifying things
around skipping heap pages via the visibility map (including removing
the FORCE_CHECK_PAGE() macro). Of course you're right that this
particular change that you have highlighted does change the behavior a
little -- now we will always treat the final page as a "scanned page",
except perhaps when 100% of all pages in the relation are skipped
using the visibility map.
This was a deliberate choice (and perhaps even a good choice!). I
think that avoiding accessing the last heap page like this isn't worth
the complexity. Note that we may already access heap pages (making
them "scanned pages") despite the fact that we know it's unnecessary:
the SKIP_PAGES_THRESHOLD test leads to this behavior (and we don't
even try to avoid wasting CPU cycles on these
not-skipped-but-skippable pages). So I think that the performance cost
for the last page isn't going to be noticeable.
However, now that I think about it, I wonder...what do you think of
SKIP_PAGES_THRESHOLD, in general? Is the optimal value still 32 today?
SKIP_PAGES_THRESHOLD hasn't changed since commit bf136cf6e3, shortly
after the original visibility map implementation was committed in
2009. The idea that it helps us to advance relfrozenxid outside of
aggressive VACUUMs (per commit message from bf136cf6e3) seems like it
might no longer matter with the patch -- because now we won't ever set
a page all-visible but not all-frozen. Plus the idea that we need to
do all this work just to get readahead from the OS
seems...questionable.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-12-21 04:28 Masahiko Sawada <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Masahiko Sawada @ 2021-12-21 04:28 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Andres Freund <[email protected]>; PostgreSQL Hackers <[email protected]>
On Sat, Dec 18, 2021 at 11:29 AM Peter Geoghegan <[email protected]> wrote:
>
> On Thu, Dec 16, 2021 at 10:46 PM Masahiko Sawada <[email protected]> wrote:
> > > My emphasis here has been on making non-aggressive VACUUMs *always*
> > > advance relfrozenxid, outside of certain obvious edge cases. And so
> > > with all the patches applied, up to and including the opportunistic
> > > freezing patch, every autovacuum of every table manages to advance
> > > relfrozenxid during benchmarking -- usually to a fairly recent value.
> > > I've focussed on making aggressive VACUUMs (especially anti-wraparound
> > > autovacuums) a rare occurrence, for truly exceptional cases (e.g.,
> > > user keeps canceling autovacuums, maybe due to automated script that
> > > performs DDL). That has taken priority over other goals, for now.
> >
> > Great!
>
> Maybe this is a good time to revisit basic questions about VACUUM. I
> wonder if we can get rid of some of the GUCs for VACUUM now.
>
> Can we fully get rid of vacuum_freeze_table_age?
Does it mean that a vacuum always is an aggressive vacuum? If
opportunistic freezing works well on all tables, we might no longer
need vacuum_freeze_table_age. But I’m not sure that’s true since the
cost of freezing tuples is not 0.
> We probably shouldn't be using any units, but using XIDs "feels wrong"
> to me. Even with my patch, it is theoretically possible that we won't
> be able to advance relfrozenxid very much, because we cannot get a
> cleanup lock on one single heap page with one old XID. But even in
> this extreme case, how relevant is the "age" of this old XID, really?
> What really matters is whether or not we can advance relfrozenxid in
> time (with time to spare). And so the wraparound risk of the system is
> not affected all that much by the age of the single oldest XID. The
> risk mostly comes from how much total work we still need to do to
> advance relfrozenxid. If the single old XID is quite old indeed (~1.5
> billion XIDs), but there is only one, then we just have to freeze one
> tuple to be able to safely advance relfrozenxid (maybe advance it by a
> huge amount!). How long can it take to freeze one tuple, with the
> freeze map, etc?
I think that that's true for (mostly) static tables. But regarding
constantly-updated tables, since autovacuum runs based on the number
of garbage tuples (or inserted tuples) and how old the relfrozenxid is
if an autovacuum could not advance the relfrozenxid because it could
not get a cleanup lock on the page that has the single oldest XID,
it's likely that when autovacuum runs next time it will have to
process other pages too since the page will get dirty enough.
It might be a good idea that we remember pages where we could not get
a cleanup lock somewhere and revisit them after index cleanup. While
revisiting the pages, we don’t prune the page but only freeze tuples.
>
> On the other hand, the risk may be far greater if we have *many*
> tuples that are still unfrozen, whose XIDs are only "middle aged"
> right now. The idea behind vacuum_freeze_min_age seems to be to be
> lazy about work (tuple freezing) in the hope that we'll never need to
> do it, but that seems obsolete now. (It probably made a little more
> sense before the visibility map.)
Why is it obsolete now? I guess that it's still valid depending on the
cases, for example, heavily updated tables.
>
> Using XIDs makes sense for things like autovacuum_freeze_max_age,
> because there we have to worry about wraparound and relfrozenxid
> (whether or not we like it). But with this patch, and with everything
> else (the failsafe, insert-driven autovacuums, everything we've done
> over the last several years) I think that it might be time to increase
> the autovacuum_freeze_max_age default. Maybe even to something as high
> as 800 million transaction IDs, but certainly to 400 million. What do
> you think? (Maybe don't answer just yet, something to think about.)
I don’t have an objection to increasing autovacuum_freeze_max_age for
now. One of my concerns with anti-wraparound vacuums is that too many
tables (or several large tables) will reach autovacuum_freeze_max_age
at once, using up autovacuum slots and preventing autovacuums from
being launched on tables that are heavily being updated. Given these
works, expanding the gap between vacuum_freeze_table_age and
autovacuum_freeze_max_age would have better chances for the tables to
advance its relfrozenxid by an aggressive vacuum instead of an
anti-wraparound-aggressive vacuum. 400 million seems to be a good
start.
>
> > + vacrel->aggressive = aggressive;
> > vacrel->failsafe_active = false;
> > vacrel->consider_bypass_optimization = true;
> >
> > How about adding skipwithvm to LVRelState too?
>
> Agreed -- it's slightly better that way. Will change this.
>
> > */
> > - if (skipping_blocks && !FORCE_CHECK_PAGE())
> > + if (skipping_blocks && blkno < nblocks - 1)
> >
> > Why do we always need to scan the last page even if heap truncation is
> > disabled (or in the failsafe mode)?
>
> My goal here was to keep the behavior from commit e8429082, "Avoid
> useless truncation attempts during VACUUM", while simplifying things
> around skipping heap pages via the visibility map (including removing
> the FORCE_CHECK_PAGE() macro). Of course you're right that this
> particular change that you have highlighted does change the behavior a
> little -- now we will always treat the final page as a "scanned page",
> except perhaps when 100% of all pages in the relation are skipped
> using the visibility map.
>
> This was a deliberate choice (and perhaps even a good choice!). I
> think that avoiding accessing the last heap page like this isn't worth
> the complexity. Note that we may already access heap pages (making
> them "scanned pages") despite the fact that we know it's unnecessary:
> the SKIP_PAGES_THRESHOLD test leads to this behavior (and we don't
> even try to avoid wasting CPU cycles on these
> not-skipped-but-skippable pages). So I think that the performance cost
> for the last page isn't going to be noticeable.
Agreed.
>
> However, now that I think about it, I wonder...what do you think of
> SKIP_PAGES_THRESHOLD, in general? Is the optimal value still 32 today?
> SKIP_PAGES_THRESHOLD hasn't changed since commit bf136cf6e3, shortly
> after the original visibility map implementation was committed in
> 2009. The idea that it helps us to advance relfrozenxid outside of
> aggressive VACUUMs (per commit message from bf136cf6e3) seems like it
> might no longer matter with the patch -- because now we won't ever set
> a page all-visible but not all-frozen. Plus the idea that we need to
> do all this work just to get readahead from the OS
> seems...questionable.
Given the opportunistic freezing, that's true but I'm concerned
whether opportunistic freezing always works well on all tables since
freezing tuples is not 0 cost.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2021-12-21 05:35 Peter Geoghegan <[email protected]>
parent: Masahiko Sawada <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Peter Geoghegan @ 2021-12-21 05:35 UTC (permalink / raw)
To: Masahiko Sawada <[email protected]>; +Cc: Andres Freund <[email protected]>; PostgreSQL Hackers <[email protected]>
On Mon, Dec 20, 2021 at 8:29 PM Masahiko Sawada <[email protected]> wrote:
> > Can we fully get rid of vacuum_freeze_table_age?
>
> Does it mean that a vacuum always is an aggressive vacuum?
No. Just somewhat more like one. Still no waiting for cleanup locks,
though. Also, autovacuum is still cancelable (that's technically from
anti-wraparound VACUUM, but you know what I mean). And there shouldn't
be a noticeable difference in terms of how many blocks can be skipped
using the VM.
> If opportunistic freezing works well on all tables, we might no longer
> need vacuum_freeze_table_age. But I’m not sure that’s true since the
> cost of freezing tuples is not 0.
That's true, of course, but right now the only goal of opportunistic
freezing is to advance relfrozenxid in every VACUUM. It needs to be
shown to be worth it, of course. But let's assume that it is worth it,
for a moment (perhaps only because we optimize freezing itself in
passing) -- then there is little use for vacuum_freeze_table_age, that
I can see.
> I think that that's true for (mostly) static tables. But regarding
> constantly-updated tables, since autovacuum runs based on the number
> of garbage tuples (or inserted tuples) and how old the relfrozenxid is
> if an autovacuum could not advance the relfrozenxid because it could
> not get a cleanup lock on the page that has the single oldest XID,
> it's likely that when autovacuum runs next time it will have to
> process other pages too since the page will get dirty enough.
I'm not arguing that the age of the single oldest XID is *totally*
irrelevant. Just that it's typically much less important than the
total amount of work we'd have to do (freezing) to be able to advance
relfrozenxid.
In any case, the extreme case where we just cannot get a cleanup lock
on one particular page with an old XID is probably very rare.
> It might be a good idea that we remember pages where we could not get
> a cleanup lock somewhere and revisit them after index cleanup. While
> revisiting the pages, we don’t prune the page but only freeze tuples.
Maybe, but I think that it would make more sense to not use
FreezeLimit for that at all. In an aggressive VACUUM (where we might
actually have to wait for a cleanup lock), why should we wait once the
age is over vacuum_freeze_min_age (usually 50 million XIDs)? The
official answer is "because we need to advance relfrozenxid". But why
not accept a much older relfrozenxid that is still sufficiently
young/safe, in order to avoid waiting for a cleanup lock?
In other words, what if our approach of "being diligent about
advancing relfrozenxid" makes the relfrozenxid problem worse, not
better? The problem with "being diligent" is that it is defined by
FreezeLimit (which is more or less the same thing as
vacuum_freeze_min_age), which is supposed to be about which tuples we
will freeze. That's a very different thing to how old relfrozenxid
should be or can be (after an aggressive VACUUM finishes).
> > On the other hand, the risk may be far greater if we have *many*
> > tuples that are still unfrozen, whose XIDs are only "middle aged"
> > right now. The idea behind vacuum_freeze_min_age seems to be to be
> > lazy about work (tuple freezing) in the hope that we'll never need to
> > do it, but that seems obsolete now. (It probably made a little more
> > sense before the visibility map.)
>
> Why is it obsolete now? I guess that it's still valid depending on the
> cases, for example, heavily updated tables.
Because after the 9.6 freezemap work we'll often set the all-visible
bit in the VM, but not the all-frozen bit (unless we have the
opportunistic freezing patch applied, which specifically avoids that).
When that happens, affected heap pages will still have
older-than-vacuum_freeze_min_age-XIDs after VACUUM runs, until we get
to an aggressive VACUUM. There could be many VACUUMs before the
aggressive VACUUM.
This "freezing cliff" seems like it might be a big problem, in
general. That's what I'm trying to address here.
Either way, the system doesn't really respect vacuum_freeze_min_age in
the way that it did before 9.6 -- which is what I meant by "obsolete".
> I don’t have an objection to increasing autovacuum_freeze_max_age for
> now. One of my concerns with anti-wraparound vacuums is that too many
> tables (or several large tables) will reach autovacuum_freeze_max_age
> at once, using up autovacuum slots and preventing autovacuums from
> being launched on tables that are heavily being updated.
I think that the patch helps with that, actually -- there tends to be
"natural variation" in the relfrozenxid age of each table, which comes
from per-table workload characteristics.
> Given these
> works, expanding the gap between vacuum_freeze_table_age and
> autovacuum_freeze_max_age would have better chances for the tables to
> advance its relfrozenxid by an aggressive vacuum instead of an
> anti-wraparound-aggressive vacuum. 400 million seems to be a good
> start.
The idea behind getting rid of vacuum_freeze_table_age (not to be
confused by the other idea about getting rid of vacuum_freeze_min_age)
is this: with the patch series, we only tend to get an anti-wraparound
VACUUM in extreme and relatively rare cases. For example, we will get
aggressive anti-wraparound VACUUMs on tables that *never* grow, but
constantly get HOT updates (e.g. the pgbench_accounts table with heap
fill factor reduced to 90). We won't really be able to use the VM when
this happens, either.
With tables like this -- tables that still get aggressive VACUUMs --
maybe the patch doesn't make a huge difference. But that's truly the
extreme case -- that is true only because there is already zero chance
of there being a non-aggressive VACUUM. We'll get aggressive
anti-wraparound VACUUMs every time we reach autovacuum_freeze_max_age,
again and again -- no change, really.
But since it's only these extreme cases that continue to get
aggressive VACUUMs, why do we still need vacuum_freeze_table_age? It
helps right now (without the patch) by "escalating" a regular VACUUM
to an aggressive one. But the cases that we still expect an aggressive
VACUUM (with the patch) are the cases where there is zero chance of
that happening. Almost by definition.
> Given the opportunistic freezing, that's true but I'm concerned
> whether opportunistic freezing always works well on all tables since
> freezing tuples is not 0 cost.
That is the big question for this patch.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-02-26 01:52 Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-02-26 01:52 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Robert Haas <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Fri, Feb 25, 2022 at 3:26 PM Andres Freund <[email protected]> wrote:
> freeze_required_limit, freeze_desired_limit? Or s/limit/cutoff/? Or
> s/limit/below/? I kind of like below because that answers < vs <= which I find
> hard to remember around freezing.
I like freeze_required_limit the most.
> That may be true, but I think working more incrementally is better in this
> are. I'd rather have a smaller improvement for a release, collect some data,
> get another improvement in the next, than see a bunch of reports of larger
> wind and large regressions.
I agree.
There is an important practical way in which it makes sense to treat
0001 as separate to 0002. It is true that 0001 is independently quite
useful. In practical terms, I'd be quite happy to just get 0001 into
Postgres 15, without 0002. I think that that's what you meant here, in
concrete terms, and we can agree on that now.
However, it is *also* true that there is an important practical sense
in which they *are* related. I don't want to ignore that either -- it
does matter. Most of the value to be had here comes from the synergy
between 0001 and 0002 -- or what I've been calling a "virtuous cycle",
the thing that makes it possible to advance relfrozenxid/relminmxid in
almost every VACUUM. Having both 0001 and 0002 together (or something
along the same lines) is way more valuable than having just one.
Perhaps we can even agree on this second point. I am encouraged by the
fact that you at least recognize the general validity of the key ideas
from 0002. If I am going to commit 0001 (and not 0002) ahead of
feature freeze for 15, I better be pretty sure that I have at least
roughly the right idea with 0002, too -- since that's the direction
that 0001 is going in. It almost seems dishonest to pretend that I
wasn't thinking of 0002 when I wrote 0001.
I'm glad that you seem to agree that this business of accumulating
freezing debt without any natural limit is just not okay. That is
really fundamental to me. I mean, vacuum_freeze_min_age kind of
doesn't work as designed. This is a huge problem for us.
> > Under these conditions, we will have many more opportunities to
> > advance relminmxid for most of the tables (including the larger
> > tables) all the way up to current-oldestMxact with the patch series.
> > Without needing to freeze *any* MultiXacts early (just freezing some
> > XIDs early) to get that benefit. The patch series is not just about
> > spreading the burden of freezing, so that non-aggressive VACUUMs
> > freeze more -- it's also making relfrozenxid and relminmxid more
> > recent and therefore *reliable* indicators of which tables any
> > wraparound problems *really* are.
>
> My concern was explicitly about the case where we have to create new
> multixacts...
It was a mistake on my part to counter your point about that with this
other point about eager relminmxid advancement. As I said in the last
email, while that is very valuable, it's not something that needs to
be brought into this.
> > Does that make sense to you?
>
> Yes.
Okay, great. The fact that you recognize the value in that comes as a relief.
> > You mean to change the signature of heap_tuple_needs_freeze, so it
> > doesn't return a bool anymore? It just has two bool pointers as
> > arguments, can_freeze and need_freeze?
>
> Something like that. Or return true if there's anything to do, and then rely
> on can_freeze and need_freeze for finer details. But it doesn't matter that much.
Got it.
> > The problem that all of these heuristics have is that they will tend
> > to make it impossible for future non-aggressive VACUUMs to be able to
> > advance relfrozenxid. All that it takes is one single all-visible page
> > to make that impossible. As I said upthread, I think that being able
> > to advance relfrozenxid (and especially relminmxid) by *some* amount
> > in every VACUUM has non-obvious value.
>
> I think that's a laudable goal. But I don't think we should go there unless we
> are quite confident we've mitigated the potential downsides.
True. But that works both ways. We also shouldn't err in the direction
of adding these kinds of heuristics (which have real downsides) until
the idea of mostly swallowing the cost of freezing whole pages (while
making it possible to disable) has lost, fairly. Overall, it looks
like the cost is acceptable in most cases.
I think that users will find it very reassuring to regularly and
reliably see confirmation that wraparound is being kept at bay, by
every VACUUM operation, with details that they can relate to their
workload. That has real value IMV -- even when it's theoretically
unnecessary for us to be so eager with advancing relfrozenxid.
I really don't like the idea of falling behind on freezing
systematically. You always run the "risk" of freezing being wasted.
But that way of looking at it can be penny wise, pound foolish --
maybe we should just accept that trying to predict what will happen in
the future (whether or not freezing will be worth it) is mostly not
helpful. Our users mostly complain about performance stability these
days. Big shocks are really something we ought to avoid. That does
have a cost. Why wouldn't it?
> > Maybe you can address that by changing the behavior of non-aggressive
> > VACUUMs, so that they are directly sensitive to this. Maybe they don't
> > skip any all-visible pages when there aren't too many, that kind of
> > thing. That needs to be in scope IMV.
>
> Yea. I still like my idea to have vacuum process a some all-visible pages
> every time and to increase that percentage based on how old the relfrozenxid
> is.
You can quite easily construct cases where the patch does much better
than that, though -- very believable cases. Any table like
pgbench_history. And so I lean towards quantifying the cost of
page-level freezing carefully, making sure there is nothing
pathological, and then just accepting it (with a GUC to disable). The
reality is that freezing is really a cost of storing data in Postgres,
and will be for the foreseeable future.
> > Can you think of an adversarial workload, to get a sense of the extent
> > of the problem?
>
> I'll try to come up with something.
That would be very helpful. Thanks!
> It might make sense to separate the purposes of SKIP_PAGES_THRESHOLD. The
> relfrozenxid advancement doesn't benefit from visiting all-frozen pages, just
> because there are only 30 of them in a row.
Right. I imagine that SKIP_PAGES_THRESHOLD actually does help with
this, but if we actually tried we'd find a much better way.
> I wish somebody would tackle merging heap_page_prune() with
> vacuuming. Primarily so we only do a single WAL record. But also because the
> separation has caused a *lot* of complexity. I've already more projects than
> I should, otherwise I'd start on it...
That has value, but it doesn't feel as urgent.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-14 04:05 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-14 04:05 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Robert Haas <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Fri, Feb 25, 2022 at 5:52 PM Peter Geoghegan <[email protected]> wrote:
> There is an important practical way in which it makes sense to treat
> 0001 as separate to 0002. It is true that 0001 is independently quite
> useful. In practical terms, I'd be quite happy to just get 0001 into
> Postgres 15, without 0002. I think that that's what you meant here, in
> concrete terms, and we can agree on that now.
Attached is v10. While this does still include the freezing patch,
it's not in scope for Postgres 15. As I've said, I still think that it
makes sense to maintain the patch series with the freezing stuff,
since it's structurally related. So, to be clear, the first two
patches from the patch series are in scope for Postgres 15. But not
the third.
Highlights:
* Changes to terminology and commit messages along the lines suggested
by Andres.
* Bug fixes to heap_tuple_needs_freeze()'s MultiXact handling. My
testing strategy here still needs work.
* Expanded refactoring by v10-0002 patch.
The v10-0002 patch (which appeared for the first time in v9) was
originally all about fixing a case where non-aggressive VACUUMs were
at a gratuitous disadvantage (relative to aggressive VACUUMs) around
advancing relfrozenxid -- very much like the lazy_scan_noprune work
from commit 44fa8488. And that is still its main purpose. But the
refactoring now seems related to Andres' idea of making non-aggressive
VACUUMs decides to scan a few extra all-visible pages in order to be
able to advance relfrozenxid.
The code that sets up skipping the visibility map is made a lot
clearer by v10-0002. That patch moves a significant amount of code
from lazy_scan_heap() into a new helper routine (so it continues the
trend started by the Postgres 14 work that added lazy_scan_prune()).
Now skipping a range of visibility map pages is fundamentally based on
setting up the range up front, and then using the same saved details
about the range thereafter -- we don't have anymore ad-hoc
VM_ALL_VISIBLE()/VM_ALL_FROZEN() calls for pages from a range that we
already decided to skip (so no calls to those routines from
lazy_scan_heap(), at least not until after we finish processing in
lazy_scan_prune()).
This is more or less what we were doing all along for one special
case: aggressive VACUUMs. We had to make sure to either increment
frozenskipped_pages or increment scanned_pages for every page from
rel_pages -- this issue is described by lazy_scan_heap() comments on
HEAD that begin with "Tricky, tricky." (these date back to the freeze
map work from 2016). Anyway, there is no reason to not go further with
that: we should make whole ranges the basic unit that we deal with
when skipping. It's a lot simpler to think in terms of entire ranges
(not individual pages) that are determined to be all-visible or
all-frozen up-front, without needing to recheck anything (regardless
of whether it's an aggressive VACUUM).
We don't need to track frozenskipped_pages this way. And it's much
more obvious that it's safe for more complicated cases, in particular
for aggressive VACUUMs.
This kind of approach seems necessary to make non-aggressive VACUUMs
do a little more work opportunistically, when they realize that they
can advance relfrozenxid relatively easily that way (which I believe
Andres favors as part of overhauling freezing). That becomes a lot
more natural when you have a clear and unambiguous separation between
deciding what range of blocks to skip, and then actually skipping. I
can imagine the new helper function added by v10-0002 (which I've
called lazy_scan_skip_range()) eventually being taught to do these
kinds of tricks.
In general I think that all of the details of what to skip need to be
decided up front. The loop in lazy_scan_heap() should execute skipping
based on the instructions it receives from the new helper function, in
the simplest way possible. The helper function can become more
intelligent about the costs and benefits of skipping in the future,
without that impacting lazy_scan_heap().
--
Peter Geoghegan
Attachments:
[application/x-patch] v10-0003-Make-page-level-characteristics-drive-freezing.patch (23.7K, ../../CAH2-WznS1rN=R-o4rdsDxUxpW4ciy5S9OGnJXa85sfDKKWA=5A@mail.gmail.com/2-v10-0003-Make-page-level-characteristics-drive-freezing.patch)
download | inline diff:
From 43ab00609392ed7ad31be491834bdac348e13653 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v10 3/3] Make page-level characteristics drive freezing.
Teach VACUUM to freeze all of the tuples on a page whenever it notices
that it would otherwise mark the page all-visible, without also marking
it all-frozen. VACUUM typically won't freeze _any_ tuples on the page
unless _all_ tuples (that remain after pruning) are all-visible. This
makes the overhead of vacuuming much more predictable over time. We
avoid the need for large balloon payments during aggressive VACUUMs
(typically anti-wraparound autovacuums). Freezing is proactive, so
we're much less likely to get into "freezing debt".
The new approach to freezing also enables relfrozenxid advancement in
non-aggressive VACUUMs, which might be enough to avoid aggressive
VACUUMs altogether (with many individual tables/workloads). While the
non-aggressive case continues to skip all-visible (but not all-frozen)
pages, that will no longer hinder relfrozenxid advancement (outside of
pg_upgrade scenarios). We now try to avoid leaving behind all-visible
(not all-frozen) pages. This (as well as work from commit 44fa84881f)
makes relfrozenxid advancement in non-aggressive VACUUMs commonplace.
There is also a clear disadvantage to the new approach to freezing: more
eager freezing will impose overhead on cases that don't receive any
benefit. This is considered an acceptable trade-off. The new algorithm
tends to avoid freezing early on pages where it makes the least sense,
since frequently modified pages are unlikely to be all-visible.
The system accumulates freezing debt in proportion to the number of
physical heap pages with unfrozen tuples, more or less. Anything based
on XID age is likely to be a poor proxy for the eventual cost of
freezing (during the inevitable anti-wraparound autovacuum). At a high
level, freezing is now treated as one of the costs of storing tuples in
physical heap pages -- not a cost of transactions that allocate XIDs.
Although vacuum_freeze_min_age and vacuum_multixact_freeze_min_age still
influence what we freeze, and when, they seldom have much influence in
many important cases.
It may still be necessary to "freeze a page" due to the presence of a
particularly old XID, from before VACUUM's FreezeLimit cutoff.
FreezeLimit can only trigger page-level freezing, though -- it cannot
change how freezing is actually executed. All XIDs < OldestXmin and all
MXIDs < OldestMxact will now be frozen on any page that VACUUM decides
to freeze, regardless of the details behind its decision.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Andres Freund <[email protected]>
Discussion: https://postgr.es/m/CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com
---
src/include/access/heapam_xlog.h | 7 +-
src/backend/access/heap/heapam.c | 92 +++++++++++++++++----
src/backend/access/heap/vacuumlazy.c | 116 ++++++++++++++++++---------
src/backend/commands/vacuum.c | 8 ++
doc/src/sgml/maintenance.sgml | 9 +--
5 files changed, 172 insertions(+), 60 deletions(-)
diff --git a/src/include/access/heapam_xlog.h b/src/include/access/heapam_xlog.h
index 2d8a7f627..2c25e72b2 100644
--- a/src/include/access/heapam_xlog.h
+++ b/src/include/access/heapam_xlog.h
@@ -409,10 +409,15 @@ extern bool heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId relminmxid,
TransactionId cutoff_xid,
TransactionId cutoff_multi,
+ TransactionId limit_xid,
+ MultiXactId limit_multi,
xl_heap_freeze_tuple *frz,
bool *totally_frozen,
+ bool *force_freeze,
TransactionId *relfrozenxid_out,
- MultiXactId *relminmxid_out);
+ MultiXactId *relminmxid_out,
+ TransactionId *relfrozenxid_nofreeze_out,
+ MultiXactId *relminmxid_nofreeze_out);
extern void heap_execute_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple *xlrec_tp);
extern XLogRecPtr log_heap_visible(RelFileNode rnode, Buffer heap_buffer,
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 2e859e427..3454201f3 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -6446,14 +6446,38 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* are older than the specified cutoff XID and cutoff MultiXactId. If so,
* setup enough state (in the *frz output argument) to later execute and
* WAL-log what we would need to do, and return true. Return false if nothing
- * is to be changed. In addition, set *totally_frozen to true if the tuple
+ * can be changed. In addition, set *totally_frozen to true if the tuple
* will be totally frozen after these operations are performed and false if
* more freezing will eventually be required.
*
+ * Although this interface is primarily tuple-based, vacuumlazy.c caller
+ * cooperates with us to decide on whether or not to freeze whole pages,
+ * together as a single group. We prepare for freezing at the level of each
+ * tuple, but the final decision is made for the page as a whole. All pages
+ * that are frozen within a given VACUUM operation are frozen according to
+ * cutoff_xid and cutoff_multi. Caller _must_ freeze the whole page when
+ * we've set *force_freeze to true!
+ *
+ * cutoff_xid must be caller's oldest xmin to ensure that any XID older than
+ * it could neither be running nor seen as running by any open transaction.
+ * This ensures that the replacement will not change anyone's idea of the
+ * tuple state. Similarly, cutoff_multi must be the smallest MultiXactId used
+ * by any open transaction (at the time that the oldest xmin was acquired).
+ *
+ * limit_xid must be <= cutoff_xid, and limit_multi must be <= cutoff_multi.
+ * When any XID/XMID from before these secondary cutoffs are encountered, we
+ * set *force_freeze to true, making caller freeze the page (freezing-eligible
+ * XIDs/XMIDs will be frozen, at least). Forcing freezing like this ensures
+ * that VACUUM won't allow XIDs/XMIDs to ever get too old. This shouldn't be
+ * necessary very often. VACUUM should prefer to freeze when it's cheap (not
+ * when it's urgent).
+ *
* Maintains *relfrozenxid_out and *relminmxid_out, which are the current
- * target relfrozenxid and relminmxid for the relation. Caller should make
- * temp copies of global tracking variables before starting to process a page,
- * so that we can only scribble on copies.
+ * target relfrozenxid and relminmxid for the relation. There are also "no
+ * freeze" variants (*relfrozenxid_nofreeze_out and *relminmxid_nofreeze_out)
+ * that are used by caller when it decides to not freeze the page. Caller
+ * should make temp copies of global tracking variables before starting to
+ * process a page, so that we can only scribble on copies.
*
* Caller is responsible for setting the offset field, if appropriate.
*
@@ -6461,13 +6485,6 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* HeapTupleSatisfiesVacuum() and determined that it is not HEAPTUPLE_DEAD
* (else we should be removing the tuple, not freezing it).
*
- * NB: cutoff_xid *must* be <= the current global xmin, to ensure that any
- * XID older than it could neither be running nor seen as running by any
- * open transaction. This ensures that the replacement will not change
- * anyone's idea of the tuple state.
- * Similarly, cutoff_multi must be less than or equal to the smallest
- * MultiXactId used by any transaction currently open.
- *
* If the tuple is in a shared buffer, caller must hold an exclusive lock on
* that buffer.
*
@@ -6479,11 +6496,16 @@ bool
heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi,
- xl_heap_freeze_tuple *frz, bool *totally_frozen,
+ TransactionId limit_xid, MultiXactId limit_multi,
+ xl_heap_freeze_tuple *frz,
+ bool *totally_frozen, bool *force_freeze,
TransactionId *relfrozenxid_out,
- MultiXactId *relminmxid_out)
+ MultiXactId *relminmxid_out,
+ TransactionId *relfrozenxid_nofreeze_out,
+ MultiXactId *relminmxid_nofreeze_out)
{
bool changed = false;
+ bool xmin_already_frozen = false;
bool xmax_already_frozen = false;
bool xmin_frozen;
bool freeze_xmax;
@@ -6504,7 +6526,10 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
*/
xid = HeapTupleHeaderGetXmin(tuple);
if (!TransactionIdIsNormal(xid))
+ {
+ xmin_already_frozen = true;
xmin_frozen = true;
+ }
else
{
if (TransactionIdPrecedes(xid, relfrozenxid))
@@ -6534,7 +6559,9 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* resolve a MultiXactId to its member Xids, in case some of them are
* below the given cutoff for Xids. In that case, those values might need
* freezing, too. Also, if a multi needs freezing, we cannot simply take
- * it out --- if there's a live updater Xid, it needs to be kept.
+ * it out --- if there's a live updater Xid, it needs to be kept. If we
+ * need to allocate a new MultiXact for that purposes, we will force
+ * caller to freeze the page.
*
* Make sure to keep heap_tuple_needs_freeze in sync with this.
*/
@@ -6580,6 +6607,12 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
Assert(TransactionIdIsValid(newxmax));
if (TransactionIdPrecedes(newxmax, *relfrozenxid_out))
*relfrozenxid_out = newxmax;
+
+ /*
+ * We have an opportunity to get rid of this MultiXact now, so
+ * force freezing to avoid wasting it
+ */
+ *force_freeze = true;
}
else if (flags & FRM_RETURN_IS_MULTI)
{
@@ -6616,6 +6649,12 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
Assert(TransactionIdPrecedesOrEquals(xmax_oldest_xid_out,
*relfrozenxid_out));
*relfrozenxid_out = xmax_oldest_xid_out;
+
+ /*
+ * We allocated a MultiXact for this, so force freezing to avoid
+ * wasting it
+ */
+ *force_freeze = true;
}
else if (flags & FRM_NOOP)
{
@@ -6734,11 +6773,27 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
Assert(!(tuple->t_infomask & HEAP_XMIN_INVALID));
frz->t_infomask |= HEAP_XMIN_COMMITTED;
changed = true;
+
+ /* Seems like a good idea to freeze early when this case is hit */
+ *force_freeze = true;
}
}
*totally_frozen = (xmin_frozen &&
(freeze_xmax || xmax_already_frozen));
+
+ /*
+ * Maintain alternative versions of relfrozenxid_out/relminmxid_out that
+ * leave caller with the option of *not* freezing the page. If caller has
+ * already lost that option (e.g. when the page has an old XID that we
+ * must force caller to freeze), then we don't waste time on this.
+ */
+ if (!*force_freeze && (!xmin_already_frozen || !xmax_already_frozen))
+ *force_freeze = heap_tuple_needs_freeze(tuple,
+ limit_xid, limit_multi,
+ relfrozenxid_nofreeze_out,
+ relminmxid_nofreeze_out);
+
return changed;
}
@@ -6790,15 +6845,22 @@ heap_freeze_tuple(HeapTupleHeader tuple,
{
xl_heap_freeze_tuple frz;
bool do_freeze;
+ bool force_freeze = true;
bool tuple_totally_frozen;
TransactionId relfrozenxid_out = cutoff_xid;
MultiXactId relminmxid_out = cutoff_multi;
+ TransactionId relfrozenxid_nofreeze_out = cutoff_xid;
+ MultiXactId relminmxid_nofreeze_out = cutoff_multi;
do_freeze = heap_prepare_freeze_tuple(tuple,
relfrozenxid, relminmxid,
cutoff_xid, cutoff_multi,
+ cutoff_xid, cutoff_multi,
&frz, &tuple_totally_frozen,
- &relfrozenxid_out, &relminmxid_out);
+ &force_freeze,
+ &relfrozenxid_out, &relminmxid_out,
+ &relfrozenxid_nofreeze_out,
+ &relminmxid_nofreeze_out);
/*
* Note that because this is not a WAL-logged operation, we don't need to
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 3bc75d401..7e2d03ba6 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -169,8 +169,9 @@ typedef struct LVRelState
/* VACUUM operation's cutoffs for freezing and pruning */
TransactionId OldestXmin;
+ MultiXactId OldestMxact;
GlobalVisState *vistest;
- /* VACUUM operation's target cutoffs for freezing XIDs and MultiXactIds */
+ /* Limits on the age of the oldest unfrozen XID and MXID */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
/* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
@@ -199,6 +200,7 @@ typedef struct LVRelState
BlockNumber rel_pages; /* total number of pages */
BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
BlockNumber removed_pages; /* # pages removed by relation truncation */
+ BlockNumber newly_frozen_pages; /* # pages frozen by lazy_scan_prune */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber missed_dead_pages; /* # pages with missed dead tuples */
BlockNumber nonempty_pages; /* actually, last nonempty page + 1 */
@@ -477,6 +479,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize page counters explicitly (be tidy) */
vacrel->scanned_pages = 0;
vacrel->removed_pages = 0;
+ vacrel->newly_frozen_pages = 0;
vacrel->lpdead_item_pages = 0;
vacrel->missed_dead_pages = 0;
vacrel->nonempty_pages = 0;
@@ -514,10 +517,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
*/
vacrel->rel_pages = orig_rel_pages = RelationGetNumberOfBlocks(rel);
vacrel->OldestXmin = OldestXmin;
+ vacrel->OldestMxact = OldestMxact;
vacrel->vistest = GlobalVisTestFor(rel);
- /* FreezeLimit controls XID freezing (always <= OldestXmin) */
+ /* FreezeLimit limits unfrozen XID age (always <= OldestXmin) */
vacrel->FreezeLimit = FreezeLimit;
- /* MultiXactCutoff controls MXID freezing (always <= OldestMxact) */
+ /* MultiXactCutoff limits unfrozen MXID age (always <= OldestMxact) */
vacrel->MultiXactCutoff = MultiXactCutoff;
/* Initialize state used to track oldest extant XID/XMID */
vacrel->NewRelfrozenXid = OldestXmin;
@@ -583,7 +587,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
*/
if (vacrel->skippedallvis)
{
- /* Cannot advance relfrozenxid/relminmxid */
+ /*
+ * Skipped some all-visible pages, so definitely cannot advance
+ * relfrozenxid. This is generally only expected in pg_upgrade
+ * scenarios, since VACUUM now avoids setting a page to all-visible
+ * but not all-frozen. However, it's also possible (though quite
+ * unlikely) that we ended up here because somebody else cleared some
+ * page's all-frozen flag (without clearing its all-visible flag).
+ */
Assert(!aggressive);
frozenxid_updated = minmulti_updated = false;
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
@@ -685,9 +696,10 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->relnamespace,
vacrel->relname,
vacrel->num_index_scans);
- appendStringInfo(&buf, _("pages: %u removed, %u remain, %u scanned (%.2f%% of total)\n"),
+ appendStringInfo(&buf, _("pages: %u removed, %u remain, %u frozen, %u scanned (%.2f%% of total)\n"),
vacrel->removed_pages,
vacrel->rel_pages,
+ vacrel->newly_frozen_pages,
vacrel->scanned_pages,
orig_rel_pages == 0 ? 100.0 :
100.0 * vacrel->scanned_pages / orig_rel_pages);
@@ -1613,8 +1625,11 @@ lazy_scan_prune(LVRelState *vacrel,
recently_dead_tuples;
int nnewlpdead;
int nfrozen;
- TransactionId NewRelfrozenXid;
- MultiXactId NewRelminMxid;
+ bool force_freeze = false;
+ TransactionId NewRelfrozenXid,
+ NoFreezeNewRelfrozenXid;
+ MultiXactId NewRelminMxid,
+ NoFreezeNewRelminMxid;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
@@ -1625,8 +1640,8 @@ lazy_scan_prune(LVRelState *vacrel,
retry:
/* Initialize (or reset) page-level state */
- NewRelfrozenXid = vacrel->NewRelfrozenXid;
- NewRelminMxid = vacrel->NewRelminMxid;
+ NewRelfrozenXid = NoFreezeNewRelfrozenXid = vacrel->NewRelfrozenXid;
+ NewRelminMxid = NoFreezeNewRelminMxid = vacrel->NewRelminMxid;
tuples_deleted = 0;
lpdead_items = 0;
live_tuples = 0;
@@ -1679,27 +1694,23 @@ retry:
continue;
}
- /*
- * LP_DEAD items are processed outside of the loop.
- *
- * Note that we deliberately don't set hastup=true in the case of an
- * LP_DEAD item here, which is not how count_nondeletable_pages() does
- * it -- it only considers pages empty/truncatable when they have no
- * items at all (except LP_UNUSED items).
- *
- * Our assumption is that any LP_DEAD items we encounter here will
- * become LP_UNUSED inside lazy_vacuum_heap_page() before we actually
- * call count_nondeletable_pages(). In any case our opinion of
- * whether or not a page 'hastup' (which is how our caller sets its
- * vacrel->nonempty_pages value) is inherently race-prone. It must be
- * treated as advisory/unreliable, so we might as well be slightly
- * optimistic.
- */
if (ItemIdIsDead(itemid))
{
+ /*
+ * Delay unsetting all_visible until after we have decided on
+ * whether this page should be frozen. We need to test "is this
+ * page all_visible, assuming any LP_DEAD items are set LP_UNUSED
+ * in final heap pass?" to reach a decision. all_visible will be
+ * unset before we return, as required by lazy_scan_heap caller.
+ *
+ * Deliberately don't set hastup for LP_DEAD items. We make the
+ * soft assumption that any LP_DEAD items encountered here will
+ * become LP_UNUSED later on, before count_nondeletable_pages is
+ * reached. Whether the page 'hastup' is inherently race-prone.
+ * It must be treated as unreliable by caller anyway, so we might
+ * as well be slightly optimistic about it.
+ */
deadoffsets[lpdead_items++] = offnum;
- prunestate->all_visible = false;
- prunestate->has_lpdead_items = true;
continue;
}
@@ -1831,11 +1842,15 @@ retry:
if (heap_prepare_freeze_tuple(tuple.t_data,
vacrel->relfrozenxid,
vacrel->relminmxid,
+ vacrel->OldestXmin,
+ vacrel->OldestMxact,
vacrel->FreezeLimit,
vacrel->MultiXactCutoff,
&frozen[nfrozen],
- &tuple_totally_frozen,
- &NewRelfrozenXid, &NewRelminMxid))
+ &tuple_totally_frozen, &force_freeze,
+ &NewRelfrozenXid, &NewRelminMxid,
+ &NoFreezeNewRelfrozenXid,
+ &NoFreezeNewRelminMxid))
{
/* Will execute freeze below */
frozen[nfrozen++].offset = offnum;
@@ -1856,9 +1871,32 @@ retry:
* that will need to be vacuumed in indexes later, or a LP_NORMAL tuple
* that remains and needs to be considered for freezing now (LP_UNUSED and
* LP_REDIRECT items also remain, but are of no further interest to us).
+ *
+ * Freeze the page when it is about to become all-visible (either just
+ * after we return control to lazy_scan_heap, or later on, during the
+ * final heap pass). Also freeze when heap_prepare_freeze_tuple forces us
+ * to freeze (this is mandatory). Freezing is typically forced because
+ * there is at least one XID/XMID from before FreezeLimit/MultiXactCutoff.
*/
- vacrel->NewRelfrozenXid = NewRelfrozenXid;
- vacrel->NewRelminMxid = NewRelminMxid;
+ if (prunestate->all_visible || force_freeze)
+ {
+ /*
+ * We're freezing the page. Our final NewRelfrozenXid doesn't need to
+ * be affected by the XIDs/XMIDs that are just about to be frozen
+ * anyway.
+ */
+ vacrel->NewRelfrozenXid = NewRelfrozenXid;
+ vacrel->NewRelminMxid = NewRelminMxid;
+ }
+ else
+ {
+ /* This is comparable to lazy_scan_noprune's handling */
+ vacrel->NewRelfrozenXid = NoFreezeNewRelfrozenXid;
+ vacrel->NewRelminMxid = NoFreezeNewRelminMxid;
+
+ /* Forget heap_prepare_freeze_tuple's guidance on freezing */
+ nfrozen = 0;
+ }
/*
* Consider the need to freeze any items with tuple storage from the page
@@ -1866,7 +1904,7 @@ retry:
*/
if (nfrozen > 0)
{
- Assert(prunestate->hastup);
+ vacrel->newly_frozen_pages++;
/*
* At least one tuple with storage needs to be frozen -- execute that
@@ -1892,11 +1930,11 @@ retry:
}
/* Now WAL-log freezing if necessary */
- if (RelationNeedsWAL(vacrel->rel))
+ if (RelationNeedsWAL(rel))
{
XLogRecPtr recptr;
- recptr = log_heap_freeze(vacrel->rel, buf, vacrel->FreezeLimit,
+ recptr = log_heap_freeze(rel, buf, NewRelfrozenXid,
frozen, nfrozen);
PageSetLSN(page, recptr);
}
@@ -1919,7 +1957,7 @@ retry:
*/
#ifdef USE_ASSERT_CHECKING
/* Note that all_frozen value does not matter when !all_visible */
- if (prunestate->all_visible)
+ if (prunestate->all_visible && lpdead_items == 0)
{
TransactionId cutoff;
bool all_frozen;
@@ -1927,7 +1965,6 @@ retry:
if (!heap_page_is_all_visible(vacrel, buf, &cutoff, &all_frozen))
Assert(false);
- Assert(lpdead_items == 0);
Assert(prunestate->all_frozen == all_frozen);
/*
@@ -1949,9 +1986,6 @@ retry:
VacDeadItems *dead_items = vacrel->dead_items;
ItemPointerData tmp;
- Assert(!prunestate->all_visible);
- Assert(prunestate->has_lpdead_items);
-
vacrel->lpdead_item_pages++;
ItemPointerSetBlockNumber(&tmp, blkno);
@@ -1965,6 +1999,10 @@ retry:
Assert(dead_items->num_items <= dead_items->max_items);
pgstat_progress_update_param(PROGRESS_VACUUM_NUM_DEAD_TUPLES,
dead_items->num_items);
+
+ /* lazy_scan_heap caller expects LP_DEAD item to unset all_visible */
+ prunestate->has_lpdead_items = true;
+ prunestate->all_visible = false;
}
/* Finally, add page-local counts to whole-VACUUM counts */
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 0ae3b4506..f1ea50454 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -957,6 +957,14 @@ get_all_vacuum_rels(int options)
* FreezeLimit (at a minimum), and relminmxid up to multiXactCutoff (at a
* minimum).
*
+ * While non-aggressive VACUUMs are never required to advance relfrozenxid and
+ * relminmxid, they often do so in practice. They freeze wherever possible,
+ * based on the same criteria that aggressive VACUUMs use. FreezeLimit and
+ * multiXactCutoff still force freezing of older XIDs/XMIDs that did not get
+ * frozen based on the standard criteria, though. (Actually, these cutoffs
+ * won't force non-aggressive VACUUMs to freeze pages that cannot be cleanup
+ * locked without waiting.)
+ *
* oldestXmin and oldestMxact are the most recent values that can ever be
* passed to vac_update_relstats() as frozenxid and minmulti arguments by our
* vacuumlazy.c caller later on. These values should be passed when it turns
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 6a02d0fa8..4d585a265 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -565,11 +565,10 @@
the <structfield>relfrozenxid</structfield> column of a table's
<structname>pg_class</structname> row contains the oldest
remaining XID at the end of the most recent <command>VACUUM</command>
- that successfully advanced <structfield>relfrozenxid</structfield>
- (typically the most recent aggressive VACUUM). All rows inserted
- by transactions with XIDs older than this cutoff XID are
- guaranteed to have been frozen. Similarly,
- the <structfield>datfrozenxid</structfield> column of a database's
+ that successfully advanced <structfield>relfrozenxid</structfield>.
+ All rows inserted by transactions with XIDs older than this cutoff
+ XID are guaranteed to have been frozen. Similarly, the
+ <structfield>datfrozenxid</structfield> column of a database's
<structname>pg_database</structname> row is a lower bound on the unfrozen XIDs
appearing in that database — it is just the minimum of the
per-table <structfield>relfrozenxid</structfield> values within the database.
--
2.30.2
[application/x-patch] v10-0001-Loosen-coupling-between-relfrozenxid-and-freezin.patch (39.9K, ../../CAH2-WznS1rN=R-o4rdsDxUxpW4ciy5S9OGnJXa85sfDKKWA=5A@mail.gmail.com/3-v10-0001-Loosen-coupling-between-relfrozenxid-and-freezin.patch)
download | inline diff:
From 19edc49f9a0f7efa5b8518285dafac620b7b8e72 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v10 1/3] Loosen coupling between relfrozenxid and freezing.
When VACUUM set relfrozenxid before now, it set it to whatever value was
used to determine which tuples to freeze -- the FreezeLimit cutoff.
This approach was very naive: the relfrozenxid invariant only requires
that new relfrozenxid values be <= the oldest extant XID remaining in
the table (at the point that the VACUUM operation ends), which in
general might be much more recent than FreezeLimit. There is no fixed
relationship between the amount of physical work performed by VACUUM to
make it safe to advance relfrozenxid (freezing and pruning), and the
actual number of XIDs that relfrozenxid can be advanced by (at least in
principle) as a result. VACUUM might have to freeze all of the tuples
from a hundred million heap pages just to enable relfrozenxid to be
advanced by no more than one or two XIDs. On the other hand, VACUUM
might end up doing little or no work, and yet still be capable of
advancing relfrozenxid by hundreds of millions of XIDs as a result.
VACUUM now sets relfrozenxid (and relminmxid) using the exact oldest
extant XID (and oldest extant MultiXactId) from the table, including
XIDs from the table's remaining/unfrozen MultiXacts. This requires that
VACUUM carefully track the oldest unfrozen XID/MultiXactId as it goes.
This optimization doesn't require any changes to the definition of
relfrozenxid, nor does it require changes to the core design of
freezing.
Later work targeting PostgreSQL 16 will teach VACUUM to determine what
to freeze based on page-level characteristics (not XID/XMID based
cutoffs). But setting relfrozenxid/relminmxid to the exact oldest
extant XID/MXID is independently useful work. For example, it is
helpful with larger databases that consume many MultiXacts. If we
assume that the largest tables don't ever need to allocate any
MultiXacts, then aggressive VACUUMs targeting those tables will now
advance relminmxid right up to OldestMxact. pg_class.relminmxid becomes
a much more precise indicator of what's really going on in each table,
making autovacuums to prevent wraparound (MultiXactId wraparound) occur
less frequently.
Final relfrozenxid values must still be >= FreezeLimit in an aggressive
VACUUM -- FreezeLimit still acts as a lower bound on the final value
that aggressive VACUUM can set relfrozenxid to. Since standard VACUUMs
still make no guarantees about advancing relfrozenxid, they might as
well set relfrozenxid to a value from well before FreezeLimit when the
opportunity presents itself. In general standard VACUUMs may now set
relfrozenxid to any value > the original relfrozenxid and <= OldestXmin.
Credit for the general idea of using the oldest extant XID to set
pg_class.relfrozenxid at the end of VACUUM goes to Andres Freund.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Andres Freund <[email protected]>
Reviewed-By: Robert Haas <[email protected]>
Discussion: https://postgr.es/m/CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com
---
src/include/access/heapam.h | 7 +-
src/include/access/heapam_xlog.h | 4 +-
src/include/commands/vacuum.h | 1 +
src/backend/access/heap/heapam.c | 247 +++++++++++++++++++++------
src/backend/access/heap/vacuumlazy.c | 119 +++++++++----
src/backend/commands/cluster.c | 5 +-
src/backend/commands/vacuum.c | 42 +++--
doc/src/sgml/maintenance.sgml | 30 +++-
8 files changed, 344 insertions(+), 111 deletions(-)
diff --git a/src/include/access/heapam.h b/src/include/access/heapam.h
index b46ab7d73..6ef3c02bb 100644
--- a/src/include/access/heapam.h
+++ b/src/include/access/heapam.h
@@ -167,8 +167,11 @@ extern void heap_inplace_update(Relation relation, HeapTuple tuple);
extern bool heap_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi);
-extern bool heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi);
+extern bool heap_tuple_needs_freeze(HeapTupleHeader tuple,
+ TransactionId limit_xid,
+ MultiXactId limit_multi,
+ TransactionId *relfrozenxid_nofreeze_out,
+ MultiXactId *relminmxid_nofreeze_out);
extern bool heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple);
extern void simple_heap_insert(Relation relation, HeapTuple tup);
diff --git a/src/include/access/heapam_xlog.h b/src/include/access/heapam_xlog.h
index 5c47fdcec..2d8a7f627 100644
--- a/src/include/access/heapam_xlog.h
+++ b/src/include/access/heapam_xlog.h
@@ -410,7 +410,9 @@ extern bool heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId cutoff_xid,
TransactionId cutoff_multi,
xl_heap_freeze_tuple *frz,
- bool *totally_frozen);
+ bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out);
extern void heap_execute_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple *xlrec_tp);
extern XLogRecPtr log_heap_visible(RelFileNode rnode, Buffer heap_buffer,
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index d64f6268f..ead88edda 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -291,6 +291,7 @@ extern bool vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff);
extern bool vacuum_xid_failsafe_check(TransactionId relfrozenxid,
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 3746336a0..2e859e427 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -6128,7 +6128,12 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* NB -- this might have the side-effect of creating a new MultiXactId!
*
* "flags" is an output value; it's used to tell caller what to do on return.
- * Possible flags are:
+ *
+ * "xmax_oldest_xid_out" is an output value; we must handle the details of
+ * tracking the oldest extant XID within Multixacts. This is part of how
+ * caller tracks relfrozenxid_out (the oldest extant XID) on behalf of VACUUM.
+ *
+ * Possible values that we can set in "flags":
* FRM_NOOP
* don't do anything -- keep existing Xmax
* FRM_INVALIDATE_XMAX
@@ -6140,12 +6145,21 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* FRM_RETURN_IS_MULTI
* The return value is a new MultiXactId to set as new Xmax.
* (caller must obtain proper infomask bits using GetMultiXactIdHintBits)
+ *
+ * Final *xmax_oldest_xid_out value should be ignored completely unless
+ * "flags" contains either FRM_NOOP or FRM_RETURN_IS_MULTI. Final value is
+ * drawn from oldest extant XID that will remain in some MultiXact (old or
+ * new) after xmax is frozen (XIDs that won't remain after freezing are
+ * ignored, per convention).
+ *
+ * Note in particular that caller must deal with FRM_RETURN_IS_XID case
+ * itself, by considering returned Xid (not using *xmax_oldest_xid_out).
*/
static TransactionId
FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, MultiXactId cutoff_multi,
- uint16 *flags)
+ uint16 *flags, TransactionId *xmax_oldest_xid_out)
{
TransactionId xid = InvalidTransactionId;
int i;
@@ -6157,6 +6171,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
bool has_lockers;
TransactionId update_xid;
bool update_committed;
+ TransactionId temp_xid_out;
*flags = 0;
@@ -6251,13 +6266,13 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
/* is there anything older than the cutoff? */
need_replace = false;
+ temp_xid_out = *xmax_oldest_xid_out; /* initialize temp_xid_out */
for (i = 0; i < nmembers; i++)
{
if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
- {
need_replace = true;
- break;
- }
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
}
/*
@@ -6266,6 +6281,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
*/
if (!need_replace)
{
+ *xmax_oldest_xid_out = temp_xid_out;
*flags |= FRM_NOOP;
pfree(members);
return InvalidTransactionId;
@@ -6275,6 +6291,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* If the multi needs to be updated, figure out which members do we need
* to keep.
*/
+ temp_xid_out = *xmax_oldest_xid_out; /* reset temp_xid_out */
nnewmembers = 0;
newmembers = palloc(sizeof(MultiXactMember) * nmembers);
has_lockers = false;
@@ -6356,7 +6373,11 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* list.)
*/
if (TransactionIdIsValid(update_xid))
+ {
newmembers[nnewmembers++] = members[i];
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
+ }
}
else
{
@@ -6366,6 +6387,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
{
/* running locker cannot possibly be older than the cutoff */
Assert(!TransactionIdPrecedes(members[i].xid, cutoff_xid));
+ Assert(!TransactionIdPrecedes(members[i].xid, *xmax_oldest_xid_out));
newmembers[nnewmembers++] = members[i];
has_lockers = true;
}
@@ -6403,6 +6425,13 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
*/
xid = MultiXactIdCreateFromMembers(nnewmembers, newmembers);
*flags |= FRM_RETURN_IS_MULTI;
+
+ /*
+ * Return oldest remaining XID in new multixact if it's older than
+ * caller's original xmax_oldest_xid_out (otherwise it's just the
+ * original xmax_oldest_xid_out value from caller)
+ */
+ *xmax_oldest_xid_out = temp_xid_out;
}
pfree(newmembers);
@@ -6421,6 +6450,11 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* will be totally frozen after these operations are performed and false if
* more freezing will eventually be required.
*
+ * Maintains *relfrozenxid_out and *relminmxid_out, which are the current
+ * target relfrozenxid and relminmxid for the relation. Caller should make
+ * temp copies of global tracking variables before starting to process a page,
+ * so that we can only scribble on copies.
+ *
* Caller is responsible for setting the offset field, if appropriate.
*
* It is assumed that the caller has checked the tuple with
@@ -6445,7 +6479,9 @@ bool
heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi,
- xl_heap_freeze_tuple *frz, bool *totally_frozen)
+ xl_heap_freeze_tuple *frz, bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out)
{
bool changed = false;
bool xmax_already_frozen = false;
@@ -6489,6 +6525,8 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
frz->t_infomask |= HEAP_XMIN_FROZEN;
changed = true;
}
+ else if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
}
/*
@@ -6506,16 +6544,21 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
{
TransactionId newxmax;
uint16 flags;
+ TransactionId xmax_oldest_xid_out = *relfrozenxid_out;
newxmax = FreezeMultiXactId(xid, tuple->t_infomask,
relfrozenxid, relminmxid,
- cutoff_xid, cutoff_multi, &flags);
+ cutoff_xid, cutoff_multi,
+ &flags, &xmax_oldest_xid_out);
freeze_xmax = (flags & FRM_INVALIDATE_XMAX);
if (flags & FRM_RETURN_IS_XID)
{
/*
+ * xmax will become an updater XID (an XID from the original
+ * MultiXact's XIDs that needs to be carried forward).
+ *
* NB -- some of these transformations are only valid because we
* know the return Xid is a tuple updater (i.e. not merely a
* locker.) Also note that the only reason we don't explicitly
@@ -6527,6 +6570,16 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
if (flags & FRM_MARK_COMMITTED)
frz->t_infomask |= HEAP_XMAX_COMMITTED;
changed = true;
+ Assert(freeze_xmax);
+
+ /*
+ * Only consider newxmax Xid to track relfrozenxid_out here, since
+ * any other XIDs from the old MultiXact won't be left behind once
+ * xmax is actually frozen.
+ */
+ Assert(TransactionIdIsValid(newxmax));
+ if (TransactionIdPrecedes(newxmax, *relfrozenxid_out))
+ *relfrozenxid_out = newxmax;
}
else if (flags & FRM_RETURN_IS_MULTI)
{
@@ -6534,6 +6587,10 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
uint16 newbits2;
/*
+ * xmax was an old MultiXactId which we have to replace with a new
+ * Multixact, that carries forward a subset of the XIDs from the
+ * original (those that we'll still need).
+ *
* We can't use GetMultiXactIdHintBits directly on the new multi
* here; that routine initializes the masks to all zeroes, which
* would lose other bits we need. Doing it this way ensures all
@@ -6548,6 +6605,37 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
frz->xmax = newxmax;
changed = true;
+ Assert(!freeze_xmax);
+
+ /*
+ * FreezeMultiXactId sets xmax_oldest_xid_out to any XID that it
+ * notices is older than initial relfrozenxid_out, unless the XID
+ * won't remain after freezing
+ */
+ Assert(!MultiXactIdPrecedes(newxmax, *relminmxid_out));
+ Assert(TransactionIdPrecedesOrEquals(xmax_oldest_xid_out,
+ *relfrozenxid_out));
+ *relfrozenxid_out = xmax_oldest_xid_out;
+ }
+ else if (flags & FRM_NOOP)
+ {
+ /*
+ * xmax is a MultiXactId, and nothing about it changes for now.
+ *
+ * Might have to ratchet back relminmxid_out, relfrozenxid_out, or
+ * both together. FreezeMultiXactId sets xmax_oldest_xid_out to
+ * any XID that it notices is older than initial relfrozenxid_out,
+ * unless the XID won't remain after freezing (or in this case
+ * after _not_ freezing).
+ */
+ Assert(MultiXactIdIsValid(xid));
+ Assert(!changed && !freeze_xmax);
+
+ if (MultiXactIdPrecedes(xid, *relminmxid_out))
+ *relminmxid_out = xid;
+ Assert(TransactionIdPrecedesOrEquals(xmax_oldest_xid_out,
+ *relfrozenxid_out));
+ *relfrozenxid_out = xmax_oldest_xid_out;
}
}
else if (TransactionIdIsNormal(xid))
@@ -6575,7 +6663,11 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
freeze_xmax = true;
}
else
+ {
freeze_xmax = false;
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ }
}
else if ((tuple->t_infomask & HEAP_XMAX_INVALID) ||
!TransactionIdIsValid(HeapTupleHeaderGetRawXmax(tuple)))
@@ -6699,11 +6791,14 @@ heap_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple frz;
bool do_freeze;
bool tuple_totally_frozen;
+ TransactionId relfrozenxid_out = cutoff_xid;
+ MultiXactId relminmxid_out = cutoff_multi;
do_freeze = heap_prepare_freeze_tuple(tuple,
relfrozenxid, relminmxid,
cutoff_xid, cutoff_multi,
- &frz, &tuple_totally_frozen);
+ &frz, &tuple_totally_frozen,
+ &relfrozenxid_out, &relminmxid_out);
/*
* Note that because this is not a WAL-logged operation, we don't need to
@@ -7133,24 +7228,57 @@ heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
* Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
* are older than the specified cutoff XID or MultiXactId. If so, return true.
*
+ * See heap_prepare_freeze_tuple for information about the basic rules for the
+ * cutoffs used here.
+ *
* It doesn't matter whether the tuple is alive or dead, we are checking
* to see if a tuple needs to be removed or frozen to avoid wraparound.
*
+ * The *relfrozenxid_nofreeze_out and *relminmxid_nofreeze_out arguments are
+ * input/output arguments that work just like heap_prepare_freeze_tuple's
+ * *relfrozenxid_out and *relminmxid_out input/output arguments. However,
+ * there is one important difference: we track the oldest extant XID and XMID
+ * while making a working assumption that no freezing will actually take
+ * place. On the other hand, heap_prepare_freeze_tuple assumes that freezing
+ * will take place (based on the specific instructions it also sets up for
+ * caller's tuple).
+ *
+ * Note, in particular, that we even assume that freezing won't go ahead for a
+ * tuple that we indicate "needs freezing" (by returning true). Not all
+ * callers will be okay with that. Caller should make temp copies of global
+ * tracking variables before starting to process a page, so that we only ever
+ * scribble on copies. That way caller can just discard the temp copies if it
+ * really needs to freeze (using heap_prepare_freeze_tuple interface). In
+ * practice aggressive VACUUM callers always do this and non-aggressive VACUUM
+ * callers always just accept an older final relfrozenxid value.
+ *
* NB: Cannot rely on hint bits here, they might not be set after a crash or
* on a standby.
*/
bool
-heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi)
+heap_tuple_needs_freeze(HeapTupleHeader tuple,
+ TransactionId limit_xid, MultiXactId limit_multi,
+ TransactionId *relfrozenxid_nofreeze_out,
+ MultiXactId *relminmxid_nofreeze_out)
{
TransactionId xid;
-
- xid = HeapTupleHeaderGetXmin(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ bool needs_freeze = false;
/*
+ * First deal with xmin.
+ */
+ xid = HeapTupleHeaderGetXmin(tuple);
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ if (TransactionIdPrecedes(xid, limit_xid))
+ needs_freeze = true;
+ }
+
+ /*
+ * Now deal with xmax.
+ *
* The considerations for multixacts are complicated; look at
* heap_prepare_freeze_tuple for justifications. This routine had better
* be in sync with that one!
@@ -7158,57 +7286,80 @@ heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
{
MultiXactId multi;
+ MultiXactMember *members;
+ int nmembers;
multi = HeapTupleHeaderGetRawXmax(tuple);
if (!MultiXactIdIsValid(multi))
{
- /* no xmax set, ignore */
- ;
+ /* no xmax set -- but xmin might still need freezing */
+ return needs_freeze;
}
- else if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
- return true;
- else if (MultiXactIdPrecedes(multi, cutoff_multi))
- return true;
- else
+
+ /*
+ * Might have to ratchet back relminmxid_nofreeze_out, which we assume
+ * won't be frozen by caller (even when we return true)
+ */
+ if (MultiXactIdPrecedes(multi, *relminmxid_nofreeze_out))
+ *relminmxid_nofreeze_out = multi;
+
+ if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
{
- MultiXactMember *members;
- int nmembers;
- int i;
-
- /* need to check whether any member of the mxact is too old */
-
- nmembers = GetMultiXactIdMembers(multi, &members, false,
- HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
-
- for (i = 0; i < nmembers; i++)
- {
- if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
- {
- pfree(members);
- return true;
- }
- }
- if (nmembers > 0)
- pfree(members);
+ /*
+ * pg_upgrade'd MultiXact doesn't need to have its XID members
+ * affect caller's relfrozenxid_nofreeze_out (just freeze it)
+ */
+ return true;
}
+ else if (MultiXactIdPrecedes(multi, limit_multi))
+ needs_freeze = true;
+
+ /*
+ * Need to check whether any member of the mxact is too old to
+ * determine if MultiXact needs to be frozen now. We even access the
+ * members when we know that the MultiXactId isn't eligible for
+ * freezing now -- we must still maintain relfrozenxid_nofreeze_out.
+ */
+ nmembers = GetMultiXactIdMembers(multi, &members, false,
+ HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
+
+ for (int i = 0; i < nmembers; i++)
+ {
+ xid = members[i].xid;
+
+ if (TransactionIdPrecedes(xid, limit_xid))
+ needs_freeze = true;
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ }
+ if (nmembers > 0)
+ pfree(members);
}
else
{
xid = HeapTupleHeaderGetRawXmax(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ if (TransactionIdPrecedes(xid, limit_xid))
+ needs_freeze = true;
+ }
}
if (tuple->t_infomask & HEAP_MOVED)
{
xid = HeapTupleHeaderGetXvac(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ if (TransactionIdPrecedes(xid, limit_xid))
+ needs_freeze = true;
+ }
}
- return false;
+ return needs_freeze;
}
/*
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 87ab7775a..9f5178e0a 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -144,7 +144,7 @@ typedef struct LVRelState
Relation *indrels;
int nindexes;
- /* Aggressive VACUUM (scan all unfrozen pages)? */
+ /* Aggressive VACUUM? (must set relfrozenxid >= FreezeLimit) */
bool aggressive;
/* Use visibility map to skip? (disabled by DISABLE_PAGE_SKIPPING) */
bool skipwithvm;
@@ -173,8 +173,9 @@ typedef struct LVRelState
/* VACUUM operation's target cutoffs for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
- /* Are FreezeLimit/MultiXactCutoff still valid? */
- bool freeze_cutoffs_valid;
+ /* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
/* Error reporting state */
char *relnamespace;
@@ -328,6 +329,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
TransactionId OldestXmin;
+ MultiXactId OldestMxact;
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
@@ -354,17 +356,17 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* used to determine which XIDs/MultiXactIds will be frozen.
*
* If this is an aggressive VACUUM, then we're strictly required to freeze
- * any and all XIDs from before FreezeLimit, so that we will be able to
- * safely advance relfrozenxid up to FreezeLimit below (we must be able to
- * advance relminmxid up to MultiXactCutoff, too).
+ * any and all XIDs from before FreezeLimit in order to be able to advance
+ * relfrozenxid to a value >= FreezeLimit below. There is an analogous
+ * requirement around MultiXact freezing, relminmxid, and MultiXactCutoff.
*/
aggressive = vacuum_set_xid_limits(rel,
params->freeze_min_age,
params->freeze_table_age,
params->multixact_freeze_min_age,
params->multixact_freeze_table_age,
- &OldestXmin, &FreezeLimit,
- &MultiXactCutoff);
+ &OldestXmin, &OldestMxact,
+ &FreezeLimit, &MultiXactCutoff);
skipwithvm = true;
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
@@ -511,10 +513,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->vistest = GlobalVisTestFor(rel);
/* FreezeLimit controls XID freezing (always <= OldestXmin) */
vacrel->FreezeLimit = FreezeLimit;
- /* MultiXactCutoff controls MXID freezing */
+ /* MultiXactCutoff controls MXID freezing (always <= OldestMxact) */
vacrel->MultiXactCutoff = MultiXactCutoff;
- /* Track if cutoffs became invalid (possible in !aggressive case only) */
- vacrel->freeze_cutoffs_valid = true;
+ /* Initialize state used to track oldest extant XID/XMID */
+ vacrel->NewRelfrozenXid = OldestXmin;
+ vacrel->NewRelminMxid = OldestMxact;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -568,12 +571,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* Aggressive VACUUM must reliably advance relfrozenxid (and relminmxid).
* We are able to advance relfrozenxid in a non-aggressive VACUUM too,
* provided we didn't skip any all-visible (not all-frozen) pages using
- * the visibility map, and assuming that we didn't fail to get a cleanup
- * lock that made it unsafe with respect to FreezeLimit (or perhaps our
- * MultiXactCutoff) established for VACUUM operation.
+ * the visibility map. A non-aggressive VACUUM might advance relfrozenxid
+ * to an XID that is either older or newer than FreezeLimit (same applies
+ * to relminmxid and MultiXactCutoff).
*/
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
- !vacrel->freeze_cutoffs_valid)
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
{
/* Cannot advance relfrozenxid/relminmxid */
Assert(!aggressive);
@@ -587,9 +589,16 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
orig_rel_pages);
+ Assert(!aggressive ||
+ TransactionIdPrecedesOrEquals(FreezeLimit,
+ vacrel->NewRelfrozenXid));
+ Assert(!aggressive ||
+ MultiXactIdPrecedesOrEquals(MultiXactCutoff,
+ vacrel->NewRelminMxid));
+
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
new_rel_allvisible, vacrel->nindexes > 0,
- FreezeLimit, MultiXactCutoff,
+ vacrel->NewRelfrozenXid, vacrel->NewRelminMxid,
&frozenxid_updated, &minmulti_updated, false);
}
@@ -694,17 +703,19 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
OldestXmin, diff);
if (frozenxid_updated)
{
- diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
+ diff = (int32) (vacrel->NewRelfrozenXid - vacrel->relfrozenxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relfrozenxid: %u, which is %d xids ahead of previous value\n"),
- FreezeLimit, diff);
+ vacrel->NewRelfrozenXid, diff);
}
if (minmulti_updated)
{
- diff = (int32) (MultiXactCutoff - vacrel->relminmxid);
+ diff = (int32) (vacrel->NewRelminMxid - vacrel->relminmxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relminmxid: %u, which is %d mxids ahead of previous value\n"),
- MultiXactCutoff, diff);
+ vacrel->NewRelminMxid, diff);
}
if (orig_rel_pages > 0)
{
@@ -896,8 +907,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
* find them. But even when aggressive *is* set, it's still OK if we miss
* a page whose all-frozen marking has just been cleared. Any new XIDs
* just added to that page are necessarily >= vacrel->OldestXmin, and so
- * they'll have no effect on the value to which we can safely set
- * relfrozenxid. A similar argument applies for MXIDs and relminmxid.
+ * they cannot invalidate NewRelfrozenXid tracking. A similar argument
+ * applies for NewRelminMxid tracking and OldestMxact.
*/
next_unskippable_block = 0;
if (vacrel->skipwithvm)
@@ -1584,6 +1595,8 @@ lazy_scan_prune(LVRelState *vacrel,
recently_dead_tuples;
int nnewlpdead;
int nfrozen;
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
@@ -1593,7 +1606,9 @@ lazy_scan_prune(LVRelState *vacrel,
retry:
- /* Initialize (or reset) page-level counters */
+ /* Initialize (or reset) page-level state */
+ NewRelfrozenXid = vacrel->NewRelfrozenXid;
+ NewRelminMxid = vacrel->NewRelminMxid;
tuples_deleted = 0;
lpdead_items = 0;
live_tuples = 0;
@@ -1801,7 +1816,8 @@ retry:
vacrel->FreezeLimit,
vacrel->MultiXactCutoff,
&frozen[nfrozen],
- &tuple_totally_frozen))
+ &tuple_totally_frozen,
+ &NewRelfrozenXid, &NewRelminMxid))
{
/* Will execute freeze below */
frozen[nfrozen++].offset = offnum;
@@ -1815,13 +1831,16 @@ retry:
prunestate->all_frozen = false;
}
+ vacrel->offnum = InvalidOffsetNumber;
+
/*
* We have now divided every item on the page into either an LP_DEAD item
* that will need to be vacuumed in indexes later, or a LP_NORMAL tuple
* that remains and needs to be considered for freezing now (LP_UNUSED and
* LP_REDIRECT items also remain, but are of no further interest to us).
*/
- vacrel->offnum = InvalidOffsetNumber;
+ vacrel->NewRelfrozenXid = NewRelfrozenXid;
+ vacrel->NewRelminMxid = NewRelminMxid;
/*
* Consider the need to freeze any items with tuple storage from the page
@@ -1972,6 +1991,8 @@ lazy_scan_noprune(LVRelState *vacrel,
missed_dead_tuples;
HeapTupleHeader tupleheader;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
+ TransactionId NoFreezeNewRelfrozenXid = vacrel->NewRelfrozenXid;
+ MultiXactId NoFreezeNewRelminMxid = vacrel->NewRelminMxid;
Assert(BufferGetBlockNumber(buf) == blkno);
@@ -2017,20 +2038,40 @@ lazy_scan_noprune(LVRelState *vacrel,
tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
if (heap_tuple_needs_freeze(tupleheader,
vacrel->FreezeLimit,
- vacrel->MultiXactCutoff))
+ vacrel->MultiXactCutoff,
+ &NoFreezeNewRelfrozenXid,
+ &NoFreezeNewRelminMxid))
{
if (vacrel->aggressive)
{
- /* Going to have to get cleanup lock for lazy_scan_prune */
+ /*
+ * heap_tuple_needs_freeze determined that it isn't going to
+ * be possible for the ongoing aggressive VACUUM operation to
+ * advance relfrozenxid to a value >= FreezeLimit without
+ * freezing one or more tuples with older XIDs from this page.
+ * (Or perhaps the issue was that MultiXactCutoff could not be
+ * respected. Might have even been both cutoffs, together.)
+ *
+ * Tell caller that it must acquire a full cleanup lock. It's
+ * possible that caller will have to wait a while for one, but
+ * that can't be helped -- full processing by lazy_scan_prune
+ * is required to freeze the older XIDs (and/or freeze older
+ * MultiXactIds).
+ */
vacrel->offnum = InvalidOffsetNumber;
return false;
}
-
- /*
- * Current non-aggressive VACUUM operation definitely won't be
- * able to advance relfrozenxid or relminmxid
- */
- vacrel->freeze_cutoffs_valid = false;
+ else
+ {
+ /*
+ * This is a non-aggressive VACUUM, which is under no strict
+ * obligation to advance relfrozenxid at all (much less to
+ * advance it to a value >= FreezeLimit). Non-aggressive
+ * VACUUM advances relfrozenxid/relminmxid on a best-effort
+ * basis. Accept an older final relfrozenxid/relminmxid value
+ * rather than waiting for a cleanup lock.
+ */
+ }
}
ItemPointerSet(&(tuple.t_self), blkno, offnum);
@@ -2079,6 +2120,16 @@ lazy_scan_noprune(LVRelState *vacrel,
vacrel->offnum = InvalidOffsetNumber;
+ /*
+ * By here we know for sure that caller can tolerate having reduced
+ * processing for this particular page. Before we return to report
+ * success, update vacrel with details of how we processed the page.
+ * (lazy_scan_prune expects a clean slate, so we have to delay these steps
+ * until here.)
+ */
+ vacrel->NewRelfrozenXid = NoFreezeNewRelfrozenXid;
+ vacrel->NewRelminMxid = NoFreezeNewRelminMxid;
+
/*
* Now save details of the LP_DEAD items from the page in vacrel (though
* only when VACUUM uses two-pass strategy)
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c
index 02a7e94bf..a7e988298 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/cluster.c
@@ -767,6 +767,7 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
TupleDesc oldTupDesc PG_USED_FOR_ASSERTS_ONLY;
TupleDesc newTupDesc PG_USED_FOR_ASSERTS_ONLY;
TransactionId OldestXmin;
+ MultiXactId oldestMxact;
TransactionId FreezeXid;
MultiXactId MultiXactCutoff;
bool use_sort;
@@ -856,8 +857,8 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
* Since we're going to rewrite the whole table anyway, there's no reason
* not to be aggressive about this.
*/
- vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0,
- &OldestXmin, &FreezeXid, &MultiXactCutoff);
+ vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0, &OldestXmin, &oldestMxact,
+ &FreezeXid, &MultiXactCutoff);
/*
* FreezeXid will become the table's new relfrozenxid, and that mustn't go
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 50a4a612e..0ae3b4506 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -945,14 +945,22 @@ get_all_vacuum_rels(int options)
* The output parameters are:
* - oldestXmin is the Xid below which tuples deleted by any xact (that
* committed) should be considered DEAD, not just RECENTLY_DEAD.
- * - freezeLimit is the Xid below which all Xids are replaced by
- * FrozenTransactionId during vacuum.
- * - multiXactCutoff is the value below which all MultiXactIds are removed
- * from Xmax.
+ * - oldestMxact is the Mxid below which MultiXacts are definitely not
+ * seen as visible by any running transaction.
+ * - freezeLimit is the Xid below which all Xids are definitely replaced by
+ * FrozenTransactionId during aggressive vacuums.
+ * - multiXactCutoff is the value below which all MultiXactIds are definitely
+ * removed from Xmax during aggressive vacuums.
*
* Return value indicates if vacuumlazy.c caller should make its VACUUM
* operation aggressive. An aggressive VACUUM must advance relfrozenxid up to
- * FreezeLimit, and relminmxid up to multiXactCutoff.
+ * FreezeLimit (at a minimum), and relminmxid up to multiXactCutoff (at a
+ * minimum).
+ *
+ * oldestXmin and oldestMxact are the most recent values that can ever be
+ * passed to vac_update_relstats() as frozenxid and minmulti arguments by our
+ * vacuumlazy.c caller later on. These values should be passed when it turns
+ * out that VACUUM will leave no unfrozen XIDs/XMIDs behind in the table.
*/
bool
vacuum_set_xid_limits(Relation rel,
@@ -961,6 +969,7 @@ vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff)
{
@@ -969,7 +978,6 @@ vacuum_set_xid_limits(Relation rel,
int effective_multixact_freeze_max_age;
TransactionId limit;
TransactionId safeLimit;
- MultiXactId oldestMxact;
MultiXactId mxactLimit;
MultiXactId safeMxactLimit;
int freezetable;
@@ -1065,9 +1073,11 @@ vacuum_set_xid_limits(Relation rel,
effective_multixact_freeze_max_age / 2);
Assert(mxid_freezemin >= 0);
+ /* Remember for caller */
+ *oldestMxact = GetOldestMultiXactId();
+
/* compute the cutoff multi, being careful to generate a valid value */
- oldestMxact = GetOldestMultiXactId();
- mxactLimit = oldestMxact - mxid_freezemin;
+ mxactLimit = *oldestMxact - mxid_freezemin;
if (mxactLimit < FirstMultiXactId)
mxactLimit = FirstMultiXactId;
@@ -1082,8 +1092,8 @@ vacuum_set_xid_limits(Relation rel,
(errmsg("oldest multixact is far in the past"),
errhint("Close open transactions with multixacts soon to avoid wraparound problems.")));
/* Use the safe limit, unless an older mxact is still running */
- if (MultiXactIdPrecedes(oldestMxact, safeMxactLimit))
- mxactLimit = oldestMxact;
+ if (MultiXactIdPrecedes(*oldestMxact, safeMxactLimit))
+ mxactLimit = *oldestMxact;
else
mxactLimit = safeMxactLimit;
}
@@ -1390,14 +1400,10 @@ vac_update_relstats(Relation relation,
* Update relfrozenxid, unless caller passed InvalidTransactionId
* indicating it has no new data.
*
- * Ordinarily, we don't let relfrozenxid go backwards: if things are
- * working correctly, the only way the new frozenxid could be older would
- * be if a previous VACUUM was done with a tighter freeze_min_age, in
- * which case we don't want to forget the work it already did. However,
- * if the stored relfrozenxid is "in the future", then it must be corrupt
- * and it seems best to overwrite it with the cutoff we used this time.
- * This should match vac_update_datfrozenxid() concerning what we consider
- * to be "in the future".
+ * Ordinarily, we don't let relfrozenxid go backwards. However, if the
+ * stored relfrozenxid is "in the future", then it must be corrupt, so
+ * just overwrite it. This should match vac_update_datfrozenxid()
+ * concerning what we consider to be "in the future".
*/
if (frozenxid_updated)
*frozenxid_updated = false;
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 36f975b1e..6a02d0fa8 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -563,9 +563,11 @@
statistics in the system tables <structname>pg_class</structname> and
<structname>pg_database</structname>. In particular,
the <structfield>relfrozenxid</structfield> column of a table's
- <structname>pg_class</structname> row contains the freeze cutoff XID that was used
- by the last aggressive <command>VACUUM</command> for that table. All rows
- inserted by transactions with XIDs older than this cutoff XID are
+ <structname>pg_class</structname> row contains the oldest
+ remaining XID at the end of the most recent <command>VACUUM</command>
+ that successfully advanced <structfield>relfrozenxid</structfield>
+ (typically the most recent aggressive VACUUM). All rows inserted
+ by transactions with XIDs older than this cutoff XID are
guaranteed to have been frozen. Similarly,
the <structfield>datfrozenxid</structfield> column of a database's
<structname>pg_database</structname> row is a lower bound on the unfrozen XIDs
@@ -588,6 +590,17 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
cutoff XID to the current transaction's XID.
</para>
+ <tip>
+ <para>
+ <literal>VACUUM VERBOSE</literal> outputs information about
+ <structfield>relfrozenxid</structfield> and/or
+ <structfield>relminmxid</structfield> when either field was
+ advanced. The same details appear in the server log when <xref
+ linkend="guc-log-autovacuum-min-duration"/> reports on vacuuming
+ by autovacuum.
+ </para>
+ </tip>
+
<para>
<command>VACUUM</command> normally only scans pages that have been modified
since the last vacuum, but <structfield>relfrozenxid</structfield> can only be
@@ -602,7 +615,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
set <literal>age(relfrozenxid)</literal> to a value just a little more than the
<varname>vacuum_freeze_min_age</varname> setting
that was used (more by the number of transactions started since the
- <command>VACUUM</command> started). If no <structfield>relfrozenxid</structfield>-advancing
+ <command>VACUUM</command> started). <command>VACUUM</command>
+ will set <structfield>relfrozenxid</structfield> to the oldest XID
+ that remains in the table, so it's possible that the final value
+ will be much more recent than strictly required.
+ If no <structfield>relfrozenxid</structfield>-advancing
<command>VACUUM</command> is issued on the table until
<varname>autovacuum_freeze_max_age</varname> is reached, an autovacuum will soon
be forced for the table.
@@ -689,8 +706,9 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
</para>
<para>
- Aggressive <command>VACUUM</command> scans, regardless of
- what causes them, enable advancing the value for that table.
+ Aggressive <command>VACUUM</command> scans, regardless of what
+ causes them, are <emphasis>guaranteed</emphasis> to be able to
+ advance the table's <structfield>relminmxid</structfield>.
Eventually, as all tables in all databases are scanned and their
oldest multixact values are advanced, on-disk storage for older
multixacts can be removed.
--
2.30.2
[application/x-patch] v10-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch (18.9K, ../../CAH2-WznS1rN=R-o4rdsDxUxpW4ciy5S9OGnJXa85sfDKKWA=5A@mail.gmail.com/4-v10-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch)
download | inline diff:
From 134bd550bd7cb8c182fe3a28789705be5bf8785a Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v10 2/3] Generalize how VACUUM skips all-frozen pages.
Non-aggressive VACUUMs were at a gratuitous disadvantage (relative to
aggressive VACUUMs) around advancing relfrozenxid before now. The
underlying issue was that lazy_scan_heap conditioned its skipping
behavior on whether or not the current VACUUM was aggressive. VACUUM
could fail to increment its frozenskipped_pages counter as a result, and
so could miss out on advancing relfrozenxid for no good reason. The
approach taken during aggressive VACUUMs avoided the problem, but that
only worked in the aggressive case.
Fix the issue by generalizing how we skip all-frozen pages: remember
whether a range of skippable pages consists only of all-frozen pages as
we're initially establishing the range of skippable pages. If we decide
to skip the range of pages, and if the range as a whole is not an
all-frozen range, remember that fact for later (this makes it unsafe to
advance relfrozenxid). We no longer need to recheck any pages using the
visibility map. We no longer directly track frozenskipped_pages at all.
And we no longer need ad-hoc VM_ALL_VISIBLE()/VM_ALL_FROZEN() calls for
pages from a range of blocks that we already decided were safe to skip.
The issue is subtle. Before now, the non-aggressive case always had to
recheck the visibility map at the point of actually skipping each page.
This created a window for some other session to concurrently unset the
same heap page's bit in the visibility map. If the bit was unset at
exactly the wrong time, then the non-aggressive case would
conservatively conclude that the page was _never_ all-frozen on recheck.
And so frozenskipped_pages would not be incremented for the page.
lazy_scan_heap had already "committed" to skipping the page at that
point, though, which was enough to make it unsafe to advance
relfrozenxid/relminmxid later on.
It's possible that this issue hardly ever came up in practice. It's
hard to be sure either way. We only had to be unlucky once to lose out
on advancing relfrozenxid -- a single affected heap page was enough to
throw VACUUM off. That seems like something to avoid on general
principle. This is similar to an issue addressed by commit 44fa8488,
which taught vacuumlazy.c to not give up on non-aggressive relfrozenxid
advancement just because a cleanup lock wasn't immediately available on
some heap page.
Also refactor the mechanism that disables skipping using the visibility
map during VACUUM(DISABLE_PAGE_SKIPPING). Our old approach made VACUUM
behave as if there were no pages with VM bits set. Our new approach has
VACUUM set up a range of pages in the usual way, without actually going
through with skipping the range in the end. This has the advantage of
making VACUUM(DISABLE_PAGE_SKIPPING) apply standard cross checks that
report on visibility map corruption via WARNINGs.
Author: Peter Geoghegan <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wzn6bGJGfOy3zSTJicKLw99PHJeSOQBOViKjSCinaxUKDQ@mail.gmail.com
---
src/backend/access/heap/vacuumlazy.c | 298 ++++++++++++++-------------
1 file changed, 158 insertions(+), 140 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 9f5178e0a..3bc75d401 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -176,6 +176,8 @@ typedef struct LVRelState
/* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
TransactionId NewRelfrozenXid;
MultiXactId NewRelminMxid;
+ /* Have we skipped any all-visible (not all-frozen) pages? */
+ bool skippedallvis;
/* Error reporting state */
char *relnamespace;
@@ -196,7 +198,6 @@ typedef struct LVRelState
VacDeadItems *dead_items; /* TIDs whose index tuples we'll delete */
BlockNumber rel_pages; /* total number of pages */
BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
- BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber removed_pages; /* # pages removed by relation truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber missed_dead_pages; /* # pages with missed dead tuples */
@@ -247,6 +248,10 @@ typedef struct LVSavedErrInfo
/* non-export function prototypes */
static void lazy_scan_heap(LVRelState *vacrel, int nworkers);
+static BlockNumber lazy_scan_skip_range(LVRelState *vacrel, Buffer *vmbuffer,
+ BlockNumber next_unskippable_block,
+ bool *all_visible_next_unskippable,
+ bool *all_frozen_skippable_range);
static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf,
BlockNumber blkno, Page page,
bool sharelock, Buffer vmbuffer);
@@ -471,7 +476,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize page counters explicitly (be tidy) */
vacrel->scanned_pages = 0;
- vacrel->frozenskipped_pages = 0;
vacrel->removed_pages = 0;
vacrel->lpdead_item_pages = 0;
vacrel->missed_dead_pages = 0;
@@ -518,6 +522,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize state used to track oldest extant XID/XMID */
vacrel->NewRelfrozenXid = OldestXmin;
vacrel->NewRelminMxid = OldestMxact;
+ /* Cannot advance relfrozenxid when we skipped all-visible pages */
+ vacrel->skippedallvis = false;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -575,7 +581,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* to an XID that is either older or newer than FreezeLimit (same applies
* to relminmxid and MultiXactCutoff).
*/
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
+ if (vacrel->skippedallvis)
{
/* Cannot advance relfrozenxid/relminmxid */
Assert(!aggressive);
@@ -587,8 +593,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
}
else
{
- Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
- orig_rel_pages);
Assert(!aggressive ||
TransactionIdPrecedesOrEquals(FreezeLimit,
vacrel->NewRelfrozenXid));
@@ -842,7 +846,9 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
next_failsafe_block,
next_fsm_block_to_vacuum;
Buffer vmbuffer = InvalidBuffer;
- bool skipping_blocks;
+ bool skipping_range,
+ all_visible_next_unskippable,
+ all_frozen_skippable_range;
const int initprog_index[] = {
PROGRESS_VACUUM_PHASE,
PROGRESS_VACUUM_TOTAL_HEAP_BLKS,
@@ -874,167 +880,85 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
pgstat_progress_update_multi_param(3, initprog_index, initprog_val);
/*
- * Set things up for skipping blocks using visibility map.
- *
- * Except when vacrel->aggressive is set, we want to skip pages that are
- * all-visible according to the visibility map, but only when we can skip
- * at least SKIP_PAGES_THRESHOLD consecutive pages. Since we're reading
- * sequentially, the OS should be doing readahead for us, so there's no
- * gain in skipping a page now and then; that's likely to disable
- * readahead and so be counterproductive. Also, skipping even a single
- * page means that we can't update relfrozenxid, so we only want to do it
- * if we can skip a goodly number of pages.
- *
- * When vacrel->aggressive is set, we can't skip pages just because they
- * are all-visible, but we can still skip pages that are all-frozen, since
- * such pages do not need freezing and do not affect the value that we can
- * safely set for relfrozenxid or relminmxid.
+ * Set up an initial range of blocks to skip via the visibility map.
*
* Before entering the main loop, establish the invariant that
* next_unskippable_block is the next block number >= blkno that we can't
- * skip based on the visibility map, either all-visible for a regular scan
- * or all-frozen for an aggressive scan. We set it to rel_pages when
- * there's no such block. We also set up the skipping_blocks flag
- * correctly at this stage.
- *
- * Note: The value returned by visibilitymap_get_status could be slightly
- * out-of-date, since we make this test before reading the corresponding
- * heap page or locking the buffer. This is OK. If we mistakenly think
- * that the page is all-visible or all-frozen when in fact the flag's just
- * been cleared, we might fail to vacuum the page. It's easy to see that
- * skipping a page when aggressive is not set is not a very big deal; we
- * might leave some dead tuples lying around, but the next vacuum will
- * find them. But even when aggressive *is* set, it's still OK if we miss
- * a page whose all-frozen marking has just been cleared. Any new XIDs
- * just added to that page are necessarily >= vacrel->OldestXmin, and so
- * they cannot invalidate NewRelfrozenXid tracking. A similar argument
- * applies for NewRelminMxid tracking and OldestMxact.
+ * skip based on the visibility map.
*/
- next_unskippable_block = 0;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmstatus;
+ next_unskippable_block = lazy_scan_skip_range(vacrel, &vmbuffer, 0,
+ &all_visible_next_unskippable,
+ &all_frozen_skippable_range);
- vmstatus = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmstatus & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
-
- if (next_unskippable_block >= SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
+ /*
+ * Decide whether or not we'll actually skip the first skippable range.
+ *
+ * We want to skip pages that are all-visible according to the visibility
+ * map (or all-frozen in the aggressive case), but only when we can skip
+ * at least SKIP_PAGES_THRESHOLD consecutive pages. Since we're reading
+ * sequentially, the OS should be doing readahead for us, so there's no
+ * gain in skipping a page now and then; that's likely to disable
+ * readahead and so be counterproductive.
+ */
+ skipping_range = (vacrel->skipwithvm &&
+ next_unskippable_block >= SKIP_PAGES_THRESHOLD);
for (blkno = 0; blkno < rel_pages; blkno++)
{
Buffer buf;
Page page;
- bool all_visible_according_to_vm = false;
+ bool all_visible_according_to_vm;
LVPagePruneState prunestate;
- pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
-
- update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
- blkno, InvalidOffsetNumber);
-
if (blkno == next_unskippable_block)
{
- /* Time to advance next_unskippable_block */
- next_unskippable_block++;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmskipflags;
-
- vmskipflags = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
+ /*
+ * We can't skip this block. It might still be all-visible,
+ * though. This can happen when an aggressive VACUUM cannot skip
+ * an all-visible block.
+ */
+ all_visible_according_to_vm = all_visible_next_unskippable;
/*
- * We know we can't skip the current block. But set up
- * skipping_blocks to do the right thing at the following blocks.
+ * Determine a range of blocks to skip after we scan and process
+ * this block. We pass blkno + 1 as next_unskippable_block. The
+ * final next_unskippable_block won't change when there are no
+ * blocks to skip (skippable blocks are those after blkno, but
+ * before final next_unskippable_block).
*/
- if (next_unskippable_block - blkno > SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
+ next_unskippable_block =
+ lazy_scan_skip_range(vacrel, &vmbuffer, blkno + 1,
+ &all_visible_next_unskippable,
+ &all_frozen_skippable_range);
- /*
- * Normally, the fact that we can't skip this block must mean that
- * it's not all-visible. But in an aggressive vacuum we know only
- * that it's not all-frozen, so it might still be all-visible.
- */
- if (vacrel->aggressive &&
- VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
- all_visible_according_to_vm = true;
+ /* Decide whether or not we'll actually skip the new range */
+ skipping_range =
+ (vacrel->skipwithvm &&
+ next_unskippable_block - blkno > SKIP_PAGES_THRESHOLD);
}
else
{
- /*
- * The current page can be skipped if we've seen a long enough run
- * of skippable blocks to justify skipping it -- provided it's not
- * the last page in the relation (according to rel_pages).
- *
- * We always scan the table's last page to determine whether it
- * has tuples or not, even if it would otherwise be skipped. This
- * avoids having lazy_truncate_heap() take access-exclusive lock
- * on the table to attempt a truncation that just fails
- * immediately because there are tuples on the last page.
- */
- if (skipping_blocks && blkno < rel_pages - 1)
+ /* Every block in the range must be safe to skip */
+ all_visible_according_to_vm = true;
+
+ Assert(blkno < next_unskippable_block);
+ Assert(blkno < rel_pages - 1); /* see lazy_scan_skip_range */
+ Assert(!vacrel->aggressive || all_frozen_skippable_range);
+
+ if (skipping_range)
{
/*
- * Tricky, tricky. If this is in aggressive vacuum, the page
- * must have been all-frozen at the time we checked whether it
- * was skippable, but it might not be any more. We must be
- * careful to count it as a skipped all-frozen page in that
- * case, or else we'll think we can't update relfrozenxid and
- * relminmxid. If it's not an aggressive vacuum, we don't
- * know whether it was initially all-frozen, so we have to
- * recheck.
+ * If this range of blocks is not all-frozen, then we cannot
+ * advance relfrozenxid later. This is another reason for
+ * SKIP_PAGES_THRESHOLD; it helps us to avoid losing out on
+ * advancing relfrozenxid where it makes the least sense.
*/
- if (vacrel->aggressive ||
- VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
- vacrel->frozenskipped_pages++;
+ if (!all_frozen_skippable_range)
+ vacrel->skippedallvis = true;
continue;
}
- /*
- * SKIP_PAGES_THRESHOLD (threshold for skipping) was not
- * crossed, or this is the last page. Scan the page, even
- * though it's all-visible (and possibly even all-frozen).
- */
- all_visible_according_to_vm = true;
+ /* We decided to not skip this range, so scan its page */
}
vacuum_delay_point();
@@ -1046,6 +970,11 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
*/
vacrel->scanned_pages++;
+ /* Report as block scanned, update error traceback information */
+ pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
+ update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
+ blkno, InvalidOffsetNumber);
+
/*
* Regularly check if wraparound failsafe should trigger.
*
@@ -1425,6 +1354,95 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
Assert(!IsInParallelMode());
}
+/*
+ * Set up a range of skippable blocks using visibility map.
+ *
+ * lazy_scan_heap() caller calls here every time it needs to set up a new
+ * range of blocks to skip via the visibility map. Caller passes the block
+ * immediately after its last next_unskippable_block to set up a new range.
+ * We return a new next_unskippable_block for this range. This is often a
+ * degenerate 0-page range (we return caller's next_unskippable_block when
+ * that happens).
+ *
+ * Sets *all_visible_next_unskippable describes whether the returned block can
+ * be assumed all-visible. Also sets *all_frozen_skippable_range to indicate
+ * whether the range is known to contain any all-visible pages.
+ *
+ * When vacrel->aggressive is set, caller can't skip pages just because they
+ * are all-visible, but can still skip pages that are all-frozen, since such
+ * pages do not need freezing and do not affect the value that we can safely
+ * set for relfrozenxid or relminmxid. *all_frozen_skippable_range is never
+ * set 'true' for aggressive callers for this reason.
+ *
+ * Note: If caller thinks that one of the pages from the range is all-visible
+ * or all-frozen when in fact the flag's just been cleared, caller might fail
+ * to vacuum the page. It's easy to see that skipping a page in a VACUUM that
+ * ultimately cannot advance relfrozenxid or relminmxid is not a very big
+ * deal; we might leave some dead tuples lying around, but the next vacuum
+ * will find them. But even in VACUUMs that *are* capable of advancing
+ * relfrozenxid, it's still OK if we miss a page whose all-frozen marking gets
+ * concurrently cleared. Any new XIDs from such a page must be >= OldestXmin,
+ * and so cannot invalidate NewRelfrozenXid tracking. A similar argument
+ * applies for NewRelminMxid tracking and OldestMxact.
+ */
+static BlockNumber
+lazy_scan_skip_range(LVRelState *vacrel, Buffer *vmbuffer,
+ BlockNumber next_unskippable_block,
+ bool *all_visible_next_unskippable,
+ bool *all_frozen_skippable_range)
+{
+ BlockNumber rel_pages = vacrel->rel_pages;
+
+ *all_visible_next_unskippable = true;
+ *all_frozen_skippable_range = true;
+
+ while (next_unskippable_block < rel_pages)
+ {
+ uint8 vmstatus;
+
+ vmstatus = visibilitymap_get_status(vacrel->rel,
+ next_unskippable_block,
+ vmbuffer);
+ if ((vmstatus & VISIBILITYMAP_ALL_VISIBLE) == 0)
+ {
+ Assert((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0);
+ *all_visible_next_unskippable = false;
+ break;
+ }
+
+ /*
+ * We always scan the table's last page later to determine whether it
+ * has tuples or not, even if it would otherwise be skipped. This
+ * avoids having lazy_truncate_heap() take access-exclusive lock on
+ * the table to attempt a truncation that just fails immediately
+ * because there are tuples on the last page.
+ */
+ if (next_unskippable_block == rel_pages - 1)
+ {
+ /* Last block case need only set all_visible_next_unskippable */
+ Assert(*all_visible_next_unskippable);
+ break;
+ }
+
+ if ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0)
+ {
+ if (vacrel->aggressive)
+ break;
+
+ /*
+ * This block may be skipped too. It's not all-frozen, though, so
+ * entire skippable range will be deemed not-all-frozen.
+ */
+ *all_frozen_skippable_range = false;
+ }
+
+ vacuum_delay_point();
+ next_unskippable_block++;
+ }
+
+ return next_unskippable_block;
+}
+
/*
* lazy_scan_new_or_empty() -- lazy_scan_heap() new/empty page handling.
*
--
2.30.2
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-23 19:59 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-23 19:59 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Robert Haas <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Sun, Mar 13, 2022 at 9:05 PM Peter Geoghegan <[email protected]> wrote:
> Attached is v10. While this does still include the freezing patch,
> it's not in scope for Postgres 15. As I've said, I still think that it
> makes sense to maintain the patch series with the freezing stuff,
> since it's structurally related.
Attached is v11. Changes:
* No longer includes the patch that adds page-level freezing. It was
making it harder to assess code coverage for the patches that I'm
targeting Postgres 15 with. And so including it with each new revision
no longer seems useful. I'll pick it up for Postgres 16.
* Extensive isolation tests added to v11-0001-*, exercising a lot of
hard-to-hit code paths that are reached when VACUUM is unable to
immediately acquire a cleanup lock on some heap page. In particular,
we now have test coverage for the code in heapam.c that handles
tracking the oldest extant XID and MXID in the presence of MultiXacts
(on a no-cleanup-lock heap page).
* v11-0002-* (which is the patch that avoids missing out on advancing
relfrozenxid in non-aggressive VACUUMs due to a race condition on
HEAD) now moves even more of the logic for deciding how VACUUM will
skip using the visibility map into its own helper routine. Now
lazy_scan_heap just does what the state returned by the helper routine
tells it about the current skippable range -- it doesn't make any
decisions itself anymore. This is far simpler than what we do
currently, on HEAD.
There are no behavioral changes here, but this approach could be
pushed further to improve performance. We could easily determine
*every* page that we're going to scan (not skip) up-front in even the
largest tables, very early, before we've even scanned one page. This
could enable things like I/O prefetching, or capping the size of the
dead_items array based on our final scanned_pages (not on rel_pages).
* A new patch (v11-0003-*) alters the behavior of VACUUM's
DISABLE_PAGE_SKIPPING option. DISABLE_PAGE_SKIPPING no longer forces
aggressive VACUUM -- now it only forces the use of the visibility map,
since that behavior is totally independent of aggressiveness.
I don't feel too strongly about the DISABLE_PAGE_SKIPPING change. It
just seems logical to decouple no-vm-skipping from aggressiveness --
it might actually be helpful in testing the work from the patch series
in the future. Any page counted in scanned_pages has essentially been
processed by VACUUM with this work in place -- that was the idea
behind the lazy_scan_noprune stuff from commit 44fa8488. Bear in mind
that the relfrozenxid tracking stuff from v11-0001-* makes it almost
certain that a DISABLE_PAGE_SKIPPING-without-aggressiveness VACUUM
will still manage to advance relfrozenxid -- usually by the same
amount as an equivalent aggressive VACUUM would anyway. (Failing to
acquire a cleanup lock on some heap page might result in the final
older relfrozenxid being appreciably older, but probably not, and we'd
still almost certainly manage to advance relfrozenxid by *some* small
amount.)
Of course, anybody that wants both an aggressive VACUUM and a VACUUM
that never skips even all-frozen pages in the visibility map will
still be able to get that behavior quite easily. For example,
VACUUM(DISABLE_PAGE_SKIPPING, FREEZE) will do that. Several of our
existing tests must already use both of these options together,
because the tests require an effective vacuum_freeze_min_age of 0 (and
vacuum_multixact_freeze_min_age of 0) -- DISABLE_PAGE_SKIPPING alone
won't do that on HEAD, which seems to confuse the issue (see commit
b700f96c for an example of that).
In other words, since DISABLE_PAGE_SKIPPING doesn't *consistently*
force lazy_scan_noprune to refuse to process a page on HEAD (it all
depends on FreezeLimit/vacuum_freeze_min_age), it is logical for
DISABLE_PAGE_SKIPPING to totally get out of the business of caring
about that -- better to limit it to caring only about the visibility
map (by no longer making it force aggressiveness).
--
Peter Geoghegan
Attachments:
[application/octet-stream] v11-0003-Don-t-force-aggressive-mode-for-DISABLE_PAGE_SKI.patch (4.6K, ../../CAH2-Wzk0C1O-MKkOrj4YAfsGRru2=cA2VQpqM-9R1HNuG3nFaQ@mail.gmail.com/2-v11-0003-Don-t-force-aggressive-mode-for-DISABLE_PAGE_SKI.patch)
download | inline diff:
From db98e5f02714bea3ce5422a68403b0a48dd280a7 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Thu, 17 Mar 2022 21:39:01 -0700
Subject: [PATCH v11 3/3] Don't force aggressive mode for
DISABLE_PAGE_SKIPPING.
It seems more natural to just make this option about the visibility map,
not whether or not individual pages are processed using lazy_scan_prune
or lazy_scan_noprune. The latter arguably doesn't really skip at all.
TODO Review implications for use of DISABLE_PAGE_SKIPPING in tests
changed by commits c2dc1a79 and fe246d1c11. This probably won't revive
the issues addressed in those commits.
VACUUM (FREEZE, DISABLE_PAGE_SKIPPING) is used for some of these tests
already, presumably because it was necessary to specify FREEZE to force
vacuum_freeze_min_age=0 to get stable results (in the individual cases
that use FREEZE too).
---
src/include/commands/vacuum.h | 2 +-
src/backend/access/heap/vacuumlazy.c | 16 ++--------------
doc/src/sgml/ref/vacuum.sgml | 15 +++++----------
3 files changed, 8 insertions(+), 25 deletions(-)
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index ead88edda..e0908012d 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -187,7 +187,7 @@ typedef struct VacAttrStats
#define VACOPT_FULL 0x10 /* FULL (non-concurrent) vacuum */
#define VACOPT_SKIP_LOCKED 0x20 /* skip if cannot get lock */
#define VACOPT_PROCESS_TOAST 0x40 /* process the TOAST table, if any */
-#define VACOPT_DISABLE_PAGE_SKIPPING 0x80 /* don't skip any pages */
+#define VACOPT_DISABLE_PAGE_SKIPPING 0x80 /* don't skip any pages via VM */
/*
* Values used by index_cleanup and truncate params.
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 49653ae99..498c2f6ee 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -320,8 +320,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
int usecs;
double read_rate,
write_rate;
- bool aggressive,
- skipwithvm;
+ bool aggressive;
bool frozenxid_updated,
minmulti_updated;
BlockNumber orig_rel_pages;
@@ -372,17 +371,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
&OldestXmin, &OldestMxact,
&FreezeLimit, &MultiXactCutoff);
- skipwithvm = true;
- if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
- {
- /*
- * Force aggressive mode, and disable skipping blocks using the
- * visibility map (even those set all-frozen)
- */
- aggressive = true;
- skipwithvm = false;
- }
-
/*
* Setup error traceback support for ereport() first. The idea is to set
* up an error context callback to display additional information on any
@@ -445,7 +433,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
Assert(params->truncate != VACOPTVALUE_UNSPECIFIED &&
params->truncate != VACOPTVALUE_AUTO);
vacrel->aggressive = aggressive;
- vacrel->skipwithvm = skipwithvm;
+ vacrel->skipwithvm = (params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0;
vacrel->failsafe_active = false;
vacrel->consider_bypass_optimization = true;
vacrel->do_index_vacuuming = true;
diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml
index 3df32b58e..aab2d6c53 100644
--- a/doc/src/sgml/ref/vacuum.sgml
+++ b/doc/src/sgml/ref/vacuum.sgml
@@ -155,16 +155,11 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ <replaceable class="paramet
<listitem>
<para>
Normally, <command>VACUUM</command> will skip pages based on the <link
- linkend="vacuum-for-visibility-map">visibility map</link>. Pages where
- all tuples are known to be frozen can always be skipped, and those
- where all tuples are known to be visible to all transactions may be
- skipped except when performing an aggressive vacuum. Furthermore,
- except when performing an aggressive vacuum, some pages may be skipped
- in order to avoid waiting for other sessions to finish using them.
- This option disables all page-skipping behavior, and is intended to
- be used only when the contents of the visibility map are
- suspect, which should happen only if there is a hardware or software
- issue causing database corruption.
+ linkend="vacuum-for-visibility-map">visibility map</link>.
+ This option disables that behavior, and is intended to be used
+ only when the contents of the visibility map are suspect, which
+ should happen only if there is a hardware or software issue
+ causing database corruption.
</para>
</listitem>
</varlistentry>
--
2.30.2
[application/octet-stream] v11-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch (19.6K, ../../CAH2-Wzk0C1O-MKkOrj4YAfsGRru2=cA2VQpqM-9R1HNuG3nFaQ@mail.gmail.com/3-v11-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch)
download | inline diff:
From c08001f3db8c279c37ca289499ccad70f524658b Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v11 2/3] Generalize how VACUUM skips all-frozen pages.
Non-aggressive VACUUMs were at a gratuitous disadvantage (relative to
aggressive VACUUMs) around advancing relfrozenxid before now. The
underlying issue was that lazy_scan_heap conditioned its skipping
behavior on whether or not the current VACUUM was aggressive. VACUUM
could fail to increment its frozenskipped_pages counter as a result, and
so could miss out on advancing relfrozenxid (in the non-aggressive case)
for no good reason.
The issue only comes up when concurrent activity might unset a page's
visibility map bit at exactly the wrong time. The non-aggressive case
rechecked the visibility map at the point of skipping each page before
now. This created a window for some other session to concurrently unset
the same heap page's bit in the visibility map. If the bit was unset at
the wrong time, it would cause VACUUM to conservatively conclude that
the page was _never_ all-frozen on recheck. frozenskipped_pages would
not be incremented for the page as a result. lazy_scan_heap had already
committed to skipping the page/range at that point, though -- which made
it unsafe to advance relfrozenxid/relminmxid later on.
Consistently avoid the issue by generalizing how we skip frozen pages
during aggressive VACUUMs: take the same approach when skipping any
skippable page range during aggressive and non-aggressive VACUUMs alike.
The new approach makes ranges (not individual pages) the fundamental
unit of skipping using the visibility map. frozenskipped_pages is
replaced with a boolean flag that represents whether some skippable
range with one or more all-visible pages was actually skipped (making
relfrozenxid unsafe to update). The VM_ALL_VISIBLE()/VM_ALL_FROZEN()
rechecks at the top of lazy_scan_heap are no longer required, since we
now record the same information in the book keeping state that tracks
the range as a whole.
There is now a clean and unambiguous separation between deciding which
contiguous pages are safe to skip (and so should be treated as a range
of skippable pages), deciding if it's worth skipping a given range, and
actually executing skipping. This separation seems like it might be
useful in the future. For example, it would now be straightforward to
teach VACUUM to assemble skippable ranges up front, via a batch process.
Many unprocessed skippable ranges could be stored in a palloc'd array;
there are no dependencies to complicate things for lazy_scan_heap later.
It's possible that the issue this commit fixes hardly ever came up in
practice. But we only had to be unlucky once to lose out on advancing
relfrozenxid -- a single affected heap page was enough to throw VACUUM
off. That seems like something to avoid on general principle. This is
similar to an issue fixed by commit 44fa8488, which taught vacuumlazy.c
to not give up on non-aggressive relfrozenxid advancement just because a
cleanup lock wasn't immediately available on some heap page.
Author: Peter Geoghegan <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wzn6bGJGfOy3zSTJicKLw99PHJeSOQBOViKjSCinaxUKDQ@mail.gmail.com
---
src/backend/access/heap/vacuumlazy.c | 311 +++++++++++++--------------
1 file changed, 146 insertions(+), 165 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index ae280d4f9..49653ae99 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -176,6 +176,7 @@ typedef struct LVRelState
/* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
TransactionId NewRelfrozenXid;
MultiXactId NewRelminMxid;
+ bool skippedallvis;
/* Error reporting state */
char *relnamespace;
@@ -196,7 +197,6 @@ typedef struct LVRelState
VacDeadItems *dead_items; /* TIDs whose index tuples we'll delete */
BlockNumber rel_pages; /* total number of pages */
BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
- BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber removed_pages; /* # pages removed by relation truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber missed_dead_pages; /* # pages with missed dead tuples */
@@ -247,6 +247,10 @@ typedef struct LVSavedErrInfo
/* non-export function prototypes */
static void lazy_scan_heap(LVRelState *vacrel, int nworkers);
+static BlockNumber lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer,
+ BlockNumber next_block,
+ bool *next_unskippable_allvis,
+ bool *skipping_current_range);
static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf,
BlockNumber blkno, Page page,
bool sharelock, Buffer vmbuffer);
@@ -471,7 +475,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize page counters explicitly (be tidy) */
vacrel->scanned_pages = 0;
- vacrel->frozenskipped_pages = 0;
vacrel->removed_pages = 0;
vacrel->lpdead_item_pages = 0;
vacrel->missed_dead_pages = 0;
@@ -518,6 +521,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize state used to track oldest extant XID/XMID */
vacrel->NewRelfrozenXid = OldestXmin;
vacrel->NewRelminMxid = OldestMxact;
+ vacrel->skippedallvis = false;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -575,7 +579,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* to an XID that is either older or newer than FreezeLimit (same applies
* to relminmxid and MultiXactCutoff).
*/
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
+ if (vacrel->skippedallvis)
{
/* Skipped an all-visible page, so cannot advance relfrozenxid */
Assert(!aggressive);
@@ -587,8 +591,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
}
else
{
- Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
- orig_rel_pages);
Assert(!aggressive ||
TransactionIdPrecedesOrEquals(FreezeLimit,
vacrel->NewRelfrozenXid));
@@ -841,7 +843,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
next_failsafe_block,
next_fsm_block_to_vacuum;
Buffer vmbuffer = InvalidBuffer;
- bool skipping_blocks;
+ bool next_unskippable_allvis,
+ skipping_current_range;
const int initprog_index[] = {
PROGRESS_VACUUM_PHASE,
PROGRESS_VACUUM_TOTAL_HEAP_BLKS,
@@ -872,179 +875,52 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
initprog_val[2] = dead_items->max_items;
pgstat_progress_update_multi_param(3, initprog_index, initprog_val);
- /*
- * Set things up for skipping blocks using visibility map.
- *
- * Except when vacrel->aggressive is set, we want to skip pages that are
- * all-visible according to the visibility map, but only when we can skip
- * at least SKIP_PAGES_THRESHOLD consecutive pages. Since we're reading
- * sequentially, the OS should be doing readahead for us, so there's no
- * gain in skipping a page now and then; that's likely to disable
- * readahead and so be counterproductive. Also, skipping even a single
- * page means that we can't update relfrozenxid, so we only want to do it
- * if we can skip a goodly number of pages.
- *
- * When vacrel->aggressive is set, we can't skip pages just because they
- * are all-visible, but we can still skip pages that are all-frozen, since
- * such pages do not need freezing and do not affect the value that we can
- * safely set for relfrozenxid or relminmxid.
- *
- * Before entering the main loop, establish the invariant that
- * next_unskippable_block is the next block number >= blkno that we can't
- * skip based on the visibility map, either all-visible for a regular scan
- * or all-frozen for an aggressive scan. We set it to rel_pages when
- * there's no such block. We also set up the skipping_blocks flag
- * correctly at this stage.
- *
- * Note: The value returned by visibilitymap_get_status could be slightly
- * out-of-date, since we make this test before reading the corresponding
- * heap page or locking the buffer. This is OK. If we mistakenly think
- * that the page is all-visible or all-frozen when in fact the flag's just
- * been cleared, we might fail to vacuum the page. It's easy to see that
- * skipping a page when aggressive is not set is not a very big deal; we
- * might leave some dead tuples lying around, but the next vacuum will
- * find them. But even when aggressive *is* set, it's still OK if we miss
- * a page whose all-frozen marking has just been cleared. Any new XIDs
- * just added to that page are necessarily >= vacrel->OldestXmin, and so
- * they cannot invalidate NewRelfrozenXid tracking. A similar argument
- * applies for NewRelminMxid tracking and OldestMxact.
- */
- next_unskippable_block = 0;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmstatus;
-
- vmstatus = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmstatus & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
-
- if (next_unskippable_block >= SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
-
+ /* Set up an initial range of skippable blocks using the visibility map */
+ next_unskippable_block = lazy_scan_skip(vacrel, &vmbuffer, 0,
+ &next_unskippable_allvis,
+ &skipping_current_range);
for (blkno = 0; blkno < rel_pages; blkno++)
{
Buffer buf;
Page page;
- bool all_visible_according_to_vm = false;
+ bool all_visible_according_to_vm;
LVPagePruneState prunestate;
- pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
-
- update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
- blkno, InvalidOffsetNumber);
-
if (blkno == next_unskippable_block)
{
- /* Time to advance next_unskippable_block */
- next_unskippable_block++;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmskipflags;
-
- vmskipflags = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
-
/*
- * We know we can't skip the current block. But set up
- * skipping_blocks to do the right thing at the following blocks.
+ * Can't skip this page safely. Must scan the page. But
+ * determine the next skippable range after the page first.
*/
- if (next_unskippable_block - blkno > SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
+ all_visible_according_to_vm = next_unskippable_allvis;
+ next_unskippable_block = lazy_scan_skip(vacrel, &vmbuffer,
+ blkno + 1,
+ &next_unskippable_allvis,
+ &skipping_current_range);
- /*
- * Normally, the fact that we can't skip this block must mean that
- * it's not all-visible. But in an aggressive vacuum we know only
- * that it's not all-frozen, so it might still be all-visible.
- */
- if (vacrel->aggressive &&
- VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
- all_visible_according_to_vm = true;
+ Assert(next_unskippable_block >= blkno + 1);
}
else
{
- /*
- * The current page can be skipped if we've seen a long enough run
- * of skippable blocks to justify skipping it -- provided it's not
- * the last page in the relation (according to rel_pages).
- *
- * We always scan the table's last page to determine whether it
- * has tuples or not, even if it would otherwise be skipped. This
- * avoids having lazy_truncate_heap() take access-exclusive lock
- * on the table to attempt a truncation that just fails
- * immediately because there are tuples on the last page.
- */
- if (skipping_blocks && blkno < rel_pages - 1)
- {
- /*
- * Tricky, tricky. If this is in aggressive vacuum, the page
- * must have been all-frozen at the time we checked whether it
- * was skippable, but it might not be any more. We must be
- * careful to count it as a skipped all-frozen page in that
- * case, or else we'll think we can't update relfrozenxid and
- * relminmxid. If it's not an aggressive vacuum, we don't
- * know whether it was initially all-frozen, so we have to
- * recheck.
- */
- if (vacrel->aggressive ||
- VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
- vacrel->frozenskipped_pages++;
- continue;
- }
+ /* Last page always scanned (may need to set nonempty_pages) */
+ Assert(blkno < rel_pages - 1);
- /*
- * SKIP_PAGES_THRESHOLD (threshold for skipping) was not
- * crossed, or this is the last page. Scan the page, even
- * though it's all-visible (and possibly even all-frozen).
- */
+ if (skipping_current_range)
+ continue;
+
+ /* Current range is too small to skip -- just scan the page */
all_visible_according_to_vm = true;
}
- vacuum_delay_point();
-
- /*
- * We're not skipping this page using the visibility map, and so it is
- * (by definition) a scanned page. Any tuples from this page are now
- * guaranteed to be counted below, after some preparatory checks.
- */
vacrel->scanned_pages++;
+ /* Report as block scanned, update error traceback information */
+ pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
+ update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
+ blkno, InvalidOffsetNumber);
+
+ vacuum_delay_point();
+
/*
* Regularly check if wraparound failsafe should trigger.
*
@@ -1244,8 +1120,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
}
/*
- * Handle setting visibility map bit based on what the VM said about
- * the page before pruning started, and using prunestate
+ * Handle setting visibility map bit based on information from the VM
+ * (as of last lazy_scan_skip() call), and from prunestate
*/
if (!all_visible_according_to_vm && prunestate.all_visible)
{
@@ -1277,9 +1153,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/*
* As of PostgreSQL 9.2, the visibility map bit should never be set if
* the page-level bit is clear. However, it's possible that the bit
- * got cleared after we checked it and before we took the buffer
- * content lock, so we must recheck before jumping to the conclusion
- * that something bad has happened.
+ * got cleared after lazy_scan_skip() was called, so we must recheck
+ * with buffer lock before concluding that the VM is corrupt.
*/
else if (all_visible_according_to_vm && !PageIsAllVisible(page)
&& VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
@@ -1318,7 +1193,7 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/*
* If the all-visible page is all-frozen but not marked as such yet,
* mark it as all-frozen. Note that all_frozen is only valid if
- * all_visible is true, so we must check both.
+ * all_visible is true, so we must check both prunestate fields.
*/
else if (all_visible_according_to_vm && prunestate.all_visible &&
prunestate.all_frozen &&
@@ -1424,6 +1299,112 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
Assert(!IsInParallelMode());
}
+/*
+ * lazy_scan_skip() -- set up range of skippable blocks using visibility map.
+ *
+ * lazy_scan_heap() calls here every time it needs to set up a new range of
+ * blocks to skip via the visibility map. Caller passes the next block in
+ * line. We return a next_unskippable_block for this range. When there are
+ * no skippable blocks we just return caller's next_block. The all-visible
+ * status of the returned block is set in *next_unskippable_allvis for caller,
+ * too. Block usually won't be all-visible (since it's unskippable), but it
+ * can be during aggressive VACUUMs (as well as in certain edge cases).
+ *
+ * Sets *skipping_current_range to indicate if caller should skip this range.
+ * Costs and benefits drive our decision. Very small ranges won't be skipped.
+ *
+ * Note: our opinion of which blocks can be skipped can go stale immediately.
+ * It's okay if caller "misses" a page whose all-visible or all-frozen marking
+ * was concurrently cleared, though. All that matters is that caller scan all
+ * pages whose tuples might contain XIDs < OldestXmin, or XMIDs < OldestMxact.
+ * (Actually, non-aggressive VACUUMs can choose to skip all-visible pages with
+ * older XIDs/MXIDs. The vacrel->skippedallvis flag will be set here when the
+ * choice to skip such a range is actually made, making everything safe.)
+ */
+static BlockNumber
+lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer, BlockNumber next_block,
+ bool *next_unskippable_allvis, bool *skipping_current_range)
+{
+ BlockNumber rel_pages = vacrel->rel_pages,
+ next_unskippable_block = next_block,
+ nskippable_blocks = 0;
+ bool allvisinrange = false;
+
+ *next_unskippable_allvis = true;
+ while (next_unskippable_block < rel_pages)
+ {
+ uint8 mapbits = visibilitymap_get_status(vacrel->rel,
+ next_unskippable_block,
+ vmbuffer);
+
+ if ((mapbits & VISIBILITYMAP_ALL_VISIBLE) == 0)
+ {
+ Assert((mapbits & VISIBILITYMAP_ALL_FROZEN) == 0);
+ *next_unskippable_allvis = false;
+ break;
+ }
+
+ /*
+ * Caller must scan the last page to determine whether it has tuples
+ * (caller must have the opportunity to set vacrel->nonempty_pages).
+ * This rule avoids having lazy_truncate_heap() take access-exclusive
+ * lock on rel to attempt a truncation that fails anyway, just because
+ * there are tuples on the last page (it is likely that there will be
+ * tuples on other nearby pages as well, but those can be skipped).
+ *
+ * Implement this by always treating the last block as unsafe to skip.
+ */
+ if (next_unskippable_block == rel_pages - 1)
+ break;
+
+ /* DISABLE_PAGE_SKIPPING makes all skipping unsafe */
+ if (!vacrel->skipwithvm)
+ break;
+
+ /*
+ * Aggressive VACUUM caller can't skip pages just because they are
+ * all-visible. They may still skip all-frozen pages, which can't
+ * contain XIDs < OldestXmin (XIDs that aren't already frozen by now).
+ */
+ if ((mapbits & VISIBILITYMAP_ALL_FROZEN) == 0)
+ {
+ if (vacrel->aggressive)
+ break;
+
+ /*
+ * All-visible block is safe to skip in non-aggressive case. But
+ * remember that the final range contains such a block for later.
+ */
+ allvisinrange = true;
+ }
+
+ vacuum_delay_point();
+ next_unskippable_block++;
+ nskippable_blocks++;
+ }
+
+ /*
+ * We only skip a range with at least SKIP_PAGES_THRESHOLD consecutive
+ * pages. Since we're reading sequentially, the OS should be doing
+ * readahead for us, so there's no gain in skipping a page now and then.
+ * Skipping such a range might even discourage sequential detection.
+ *
+ * This test also enables more frequent relfrozenxid advancement during
+ * non-aggressive VACUUMs. If the range has any all-visible pages then
+ * skipping makes updating relfrozenxid unsafe, which is a real downside.
+ */
+ if (nskippable_blocks < SKIP_PAGES_THRESHOLD)
+ *skipping_current_range = false;
+ else
+ {
+ *skipping_current_range = true;
+ if (allvisinrange)
+ vacrel->skippedallvis = true;
+ }
+
+ return next_unskippable_block;
+}
+
/*
* lazy_scan_new_or_empty() -- lazy_scan_heap() new/empty page handling.
*
--
2.30.2
[application/octet-stream] v11-0001-Loosen-coupling-between-relfrozenxid-and-freezin.patch (53.1K, ../../CAH2-Wzk0C1O-MKkOrj4YAfsGRru2=cA2VQpqM-9R1HNuG3nFaQ@mail.gmail.com/4-v11-0001-Loosen-coupling-between-relfrozenxid-and-freezin.patch)
download | inline diff:
From b3b90046078fbddc8e4b2287a5d04b2cb5142cc6 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v11 1/3] Loosen coupling between relfrozenxid and freezing.
When VACUUM set relfrozenxid before now, it set it to whatever value was
used to determine which tuples to freeze -- the FreezeLimit cutoff.
This approach was very naive: the relfrozenxid invariant only requires
that new relfrozenxid values be <= the oldest extant XID remaining in
the table (at the point that the VACUUM operation ends), which in
general might be much more recent than FreezeLimit. There is no fixed
relationship between the amount of physical work performed by VACUUM to
make it safe to advance relfrozenxid (freezing and pruning), and the
actual number of XIDs that relfrozenxid can be advanced by (at least in
principle) as a result. VACUUM might have to freeze all of the tuples
from a hundred million heap pages just to enable relfrozenxid to be
advanced by no more than one or two XIDs. On the other hand, VACUUM
might end up doing little or no work, and yet still be capable of
advancing relfrozenxid by hundreds of millions of XIDs as a result.
VACUUM now sets relfrozenxid (and relminmxid) using the exact oldest
extant XID (and oldest extant MultiXactId) from the table, including
XIDs from the table's remaining/unfrozen MultiXacts. This requires that
VACUUM carefully track the oldest unfrozen XID/MultiXactId as it goes.
This optimization doesn't require any changes to the definition of
relfrozenxid, nor does it require changes to the core design of
freezing.
Later work targeting PostgreSQL 16 will teach VACUUM to determine what
to freeze based on page-level characteristics (not XID/XMID based
cutoffs). But setting relfrozenxid/relminmxid to the exact oldest
extant XID/MXID is independently useful work. For example, it is
helpful with larger databases that consume many MultiXacts. If we
assume that the largest tables don't ever need to allocate any
MultiXacts, then aggressive VACUUMs targeting those tables will now
advance relminmxid right up to OldestMxact. pg_class.relminmxid becomes
a much more precise indicator of what's really going on in each table,
making autovacuums to prevent wraparound (MultiXactId wraparound) occur
less frequently.
Final relfrozenxid values must still be >= FreezeLimit in an aggressive
VACUUM -- FreezeLimit still acts as a lower bound on the final value
that aggressive VACUUM can set relfrozenxid to. Since standard VACUUMs
still make no guarantees about advancing relfrozenxid, they might as
well set relfrozenxid to a value from well before FreezeLimit when the
opportunity presents itself. In general standard VACUUMs may now set
relfrozenxid to any value > the original relfrozenxid and <= OldestXmin.
Credit for the general idea of using the oldest extant XID to set
pg_class.relfrozenxid at the end of VACUUM goes to Andres Freund.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Andres Freund <[email protected]>
Reviewed-By: Robert Haas <[email protected]>
Discussion: https://postgr.es/m/CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com
---
src/include/access/heapam.h | 7 +-
src/include/access/heapam_xlog.h | 4 +-
src/include/commands/vacuum.h | 1 +
src/backend/access/heap/heapam.c | 244 ++++++++++++++----
src/backend/access/heap/vacuumlazy.c | 120 ++++++---
src/backend/commands/cluster.c | 5 +-
src/backend/commands/vacuum.c | 42 +--
doc/src/sgml/maintenance.sgml | 30 ++-
.../expected/vacuum-no-cleanup-lock.out | 188 ++++++++++++++
.../isolation/expected/vacuum-reltuples.out | 67 -----
src/test/isolation/isolation_schedule | 2 +-
.../specs/vacuum-no-cleanup-lock.spec | 145 +++++++++++
.../isolation/specs/vacuum-reltuples.spec | 49 ----
13 files changed, 675 insertions(+), 229 deletions(-)
create mode 100644 src/test/isolation/expected/vacuum-no-cleanup-lock.out
delete mode 100644 src/test/isolation/expected/vacuum-reltuples.out
create mode 100644 src/test/isolation/specs/vacuum-no-cleanup-lock.spec
delete mode 100644 src/test/isolation/specs/vacuum-reltuples.spec
diff --git a/src/include/access/heapam.h b/src/include/access/heapam.h
index b46ab7d73..6ef3c02bb 100644
--- a/src/include/access/heapam.h
+++ b/src/include/access/heapam.h
@@ -167,8 +167,11 @@ extern void heap_inplace_update(Relation relation, HeapTuple tuple);
extern bool heap_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi);
-extern bool heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi);
+extern bool heap_tuple_needs_freeze(HeapTupleHeader tuple,
+ TransactionId limit_xid,
+ MultiXactId limit_multi,
+ TransactionId *relfrozenxid_nofreeze_out,
+ MultiXactId *relminmxid_nofreeze_out);
extern bool heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple);
extern void simple_heap_insert(Relation relation, HeapTuple tup);
diff --git a/src/include/access/heapam_xlog.h b/src/include/access/heapam_xlog.h
index 5c47fdcec..2d8a7f627 100644
--- a/src/include/access/heapam_xlog.h
+++ b/src/include/access/heapam_xlog.h
@@ -410,7 +410,9 @@ extern bool heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId cutoff_xid,
TransactionId cutoff_multi,
xl_heap_freeze_tuple *frz,
- bool *totally_frozen);
+ bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out);
extern void heap_execute_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple *xlrec_tp);
extern XLogRecPtr log_heap_visible(RelFileNode rnode, Buffer heap_buffer,
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index d64f6268f..ead88edda 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -291,6 +291,7 @@ extern bool vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff);
extern bool vacuum_xid_failsafe_check(TransactionId relfrozenxid,
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 3746336a0..5a3c18413 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -6128,7 +6128,12 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* NB -- this might have the side-effect of creating a new MultiXactId!
*
* "flags" is an output value; it's used to tell caller what to do on return.
- * Possible flags are:
+ *
+ * "xmax_oldest_xid_out" is an output value; we must handle the details of
+ * tracking the oldest extant XID within Multixacts. This is part of how
+ * caller tracks relfrozenxid_out (the oldest extant XID) on behalf of VACUUM.
+ *
+ * Possible values that we can set in "flags":
* FRM_NOOP
* don't do anything -- keep existing Xmax
* FRM_INVALIDATE_XMAX
@@ -6140,12 +6145,21 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* FRM_RETURN_IS_MULTI
* The return value is a new MultiXactId to set as new Xmax.
* (caller must obtain proper infomask bits using GetMultiXactIdHintBits)
+ *
+ * Final *xmax_oldest_xid_out value should be ignored completely unless
+ * "flags" contains either FRM_NOOP or FRM_RETURN_IS_MULTI. Final value is
+ * drawn from oldest extant XID that will remain in some MultiXact (old or
+ * new) after xmax is frozen (XIDs that won't remain after freezing are
+ * ignored, per the general convention).
+ *
+ * Note in particular that caller must deal with FRM_RETURN_IS_XID case
+ * itself, by considering returned Xid (not using *xmax_oldest_xid_out).
*/
static TransactionId
FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, MultiXactId cutoff_multi,
- uint16 *flags)
+ uint16 *flags, TransactionId *xmax_oldest_xid_out)
{
TransactionId xid = InvalidTransactionId;
int i;
@@ -6157,6 +6171,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
bool has_lockers;
TransactionId update_xid;
bool update_committed;
+ TransactionId temp_xid_out;
*flags = 0;
@@ -6251,13 +6266,13 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
/* is there anything older than the cutoff? */
need_replace = false;
+ temp_xid_out = *xmax_oldest_xid_out; /* initialize temp_xid_out */
for (i = 0; i < nmembers; i++)
{
if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
- {
need_replace = true;
- break;
- }
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
}
/*
@@ -6266,6 +6281,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
*/
if (!need_replace)
{
+ *xmax_oldest_xid_out = temp_xid_out;
*flags |= FRM_NOOP;
pfree(members);
return InvalidTransactionId;
@@ -6275,6 +6291,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* If the multi needs to be updated, figure out which members do we need
* to keep.
*/
+ temp_xid_out = *xmax_oldest_xid_out; /* reset temp_xid_out */
nnewmembers = 0;
newmembers = palloc(sizeof(MultiXactMember) * nmembers);
has_lockers = false;
@@ -6356,7 +6373,11 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* list.)
*/
if (TransactionIdIsValid(update_xid))
+ {
newmembers[nnewmembers++] = members[i];
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
+ }
}
else
{
@@ -6366,6 +6387,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
{
/* running locker cannot possibly be older than the cutoff */
Assert(!TransactionIdPrecedes(members[i].xid, cutoff_xid));
+ Assert(!TransactionIdPrecedes(members[i].xid, *xmax_oldest_xid_out));
newmembers[nnewmembers++] = members[i];
has_lockers = true;
}
@@ -6403,6 +6425,13 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
*/
xid = MultiXactIdCreateFromMembers(nnewmembers, newmembers);
*flags |= FRM_RETURN_IS_MULTI;
+
+ /*
+ * Return oldest remaining XID in new multixact if it's older than
+ * caller's original xmax_oldest_xid_out (otherwise it's just the
+ * original xmax_oldest_xid_out value from caller)
+ */
+ *xmax_oldest_xid_out = temp_xid_out;
}
pfree(newmembers);
@@ -6421,6 +6450,11 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* will be totally frozen after these operations are performed and false if
* more freezing will eventually be required.
*
+ * Maintains *relfrozenxid_out and *relminmxid_out, which are the current
+ * target relfrozenxid and relminmxid for the relation. Caller should make
+ * temp copies of global tracking variables before starting to process a page,
+ * so that we can only scribble on copies.
+ *
* Caller is responsible for setting the offset field, if appropriate.
*
* It is assumed that the caller has checked the tuple with
@@ -6445,7 +6479,9 @@ bool
heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi,
- xl_heap_freeze_tuple *frz, bool *totally_frozen)
+ xl_heap_freeze_tuple *frz, bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out)
{
bool changed = false;
bool xmax_already_frozen = false;
@@ -6489,6 +6525,8 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
frz->t_infomask |= HEAP_XMIN_FROZEN;
changed = true;
}
+ else if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
}
/*
@@ -6506,16 +6544,21 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
{
TransactionId newxmax;
uint16 flags;
+ TransactionId xmax_oldest_xid_out = *relfrozenxid_out;
newxmax = FreezeMultiXactId(xid, tuple->t_infomask,
relfrozenxid, relminmxid,
- cutoff_xid, cutoff_multi, &flags);
+ cutoff_xid, cutoff_multi,
+ &flags, &xmax_oldest_xid_out);
freeze_xmax = (flags & FRM_INVALIDATE_XMAX);
if (flags & FRM_RETURN_IS_XID)
{
/*
+ * xmax will become an updater XID (an XID from the original
+ * MultiXact's XIDs that needs to be carried forward).
+ *
* NB -- some of these transformations are only valid because we
* know the return Xid is a tuple updater (i.e. not merely a
* locker.) Also note that the only reason we don't explicitly
@@ -6527,6 +6570,16 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
if (flags & FRM_MARK_COMMITTED)
frz->t_infomask |= HEAP_XMAX_COMMITTED;
changed = true;
+ Assert(freeze_xmax);
+
+ /*
+ * Only consider newxmax Xid to track relfrozenxid_out here, since
+ * any other XIDs from the old MultiXact won't be left behind once
+ * xmax is actually frozen.
+ */
+ Assert(TransactionIdIsValid(newxmax));
+ if (TransactionIdPrecedes(newxmax, *relfrozenxid_out))
+ *relfrozenxid_out = newxmax;
}
else if (flags & FRM_RETURN_IS_MULTI)
{
@@ -6534,6 +6587,10 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
uint16 newbits2;
/*
+ * xmax was an old MultiXactId which we have to replace with a new
+ * Multixact, that carries forward a subset of the XIDs from the
+ * original (those that we'll still need).
+ *
* We can't use GetMultiXactIdHintBits directly on the new multi
* here; that routine initializes the masks to all zeroes, which
* would lose other bits we need. Doing it this way ensures all
@@ -6548,6 +6605,37 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
frz->xmax = newxmax;
changed = true;
+ Assert(!freeze_xmax);
+
+ /*
+ * FreezeMultiXactId sets xmax_oldest_xid_out to any XID that it
+ * notices is older than initial relfrozenxid_out, unless the XID
+ * won't remain after freezing
+ */
+ Assert(!MultiXactIdPrecedes(newxmax, *relminmxid_out));
+ Assert(TransactionIdPrecedesOrEquals(xmax_oldest_xid_out,
+ *relfrozenxid_out));
+ *relfrozenxid_out = xmax_oldest_xid_out;
+ }
+ else if (flags & FRM_NOOP)
+ {
+ /*
+ * xmax is a MultiXactId, and nothing about it changes for now.
+ *
+ * Might have to ratchet back relminmxid_out, relfrozenxid_out, or
+ * both together. FreezeMultiXactId sets xmax_oldest_xid_out to
+ * any XID that it notices is older than initial relfrozenxid_out,
+ * unless the XID won't remain after freezing (or in this case
+ * after _not_ freezing).
+ */
+ Assert(MultiXactIdIsValid(xid));
+ Assert(!freeze_xmax);
+
+ if (MultiXactIdPrecedes(xid, *relminmxid_out))
+ *relminmxid_out = xid;
+ Assert(TransactionIdPrecedesOrEquals(xmax_oldest_xid_out,
+ *relfrozenxid_out));
+ *relfrozenxid_out = xmax_oldest_xid_out;
}
}
else if (TransactionIdIsNormal(xid))
@@ -6575,7 +6663,11 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
freeze_xmax = true;
}
else
+ {
freeze_xmax = false;
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ }
}
else if ((tuple->t_infomask & HEAP_XMAX_INVALID) ||
!TransactionIdIsValid(HeapTupleHeaderGetRawXmax(tuple)))
@@ -6699,11 +6791,14 @@ heap_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple frz;
bool do_freeze;
bool tuple_totally_frozen;
+ TransactionId relfrozenxid_out = cutoff_xid;
+ MultiXactId relminmxid_out = cutoff_multi;
do_freeze = heap_prepare_freeze_tuple(tuple,
relfrozenxid, relminmxid,
cutoff_xid, cutoff_multi,
- &frz, &tuple_totally_frozen);
+ &frz, &tuple_totally_frozen,
+ &relfrozenxid_out, &relminmxid_out);
/*
* Note that because this is not a WAL-logged operation, we don't need to
@@ -7133,24 +7228,54 @@ heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
* Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
* are older than the specified cutoff XID or MultiXactId. If so, return true.
*
+ * See heap_prepare_freeze_tuple for information about the basic rules for the
+ * cutoffs used here.
+ *
* It doesn't matter whether the tuple is alive or dead, we are checking
* to see if a tuple needs to be removed or frozen to avoid wraparound.
*
+ * The *relfrozenxid_nofreeze_out and *relminmxid_nofreeze_out arguments are
+ * input/output arguments that work just like heap_prepare_freeze_tuple's
+ * *relfrozenxid_out and *relminmxid_out input/output arguments. However,
+ * there is one important difference: we track the oldest extant XID and XMID
+ * while making a working assumption that no freezing will actually take
+ * place. On the other hand, heap_prepare_freeze_tuple assumes that freezing
+ * will take place (based on the specific instructions it also sets up for
+ * caller's tuple).
+ *
+ * Note, in particular, that we even assume that freezing won't go ahead for a
+ * tuple that we indicate "needs freezing" (by returning true). Not all
+ * callers will be okay with that. Caller should make temp copies of global
+ * tracking variables, and pass us those. That way caller can back out at the
+ * last moment when it must freeze the tuple using heap_prepare_freeze_tuple.
+ *
* NB: Cannot rely on hint bits here, they might not be set after a crash or
* on a standby.
*/
bool
-heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi)
+heap_tuple_needs_freeze(HeapTupleHeader tuple,
+ TransactionId limit_xid, MultiXactId limit_multi,
+ TransactionId *relfrozenxid_nofreeze_out,
+ MultiXactId *relminmxid_nofreeze_out)
{
TransactionId xid;
-
- xid = HeapTupleHeaderGetXmin(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ bool needs_freeze = false;
/*
+ * First deal with xmin.
+ */
+ xid = HeapTupleHeaderGetXmin(tuple);
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ if (TransactionIdPrecedes(xid, limit_xid))
+ needs_freeze = true;
+ }
+
+ /*
+ * Now deal with xmax.
+ *
* The considerations for multixacts are complicated; look at
* heap_prepare_freeze_tuple for justifications. This routine had better
* be in sync with that one!
@@ -7158,57 +7283,80 @@ heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
{
MultiXactId multi;
+ MultiXactMember *members;
+ int nmembers;
multi = HeapTupleHeaderGetRawXmax(tuple);
if (!MultiXactIdIsValid(multi))
{
- /* no xmax set, ignore */
- ;
+ /* no xmax set -- but xmin might still need freezing */
+ return needs_freeze;
}
- else if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
- return true;
- else if (MultiXactIdPrecedes(multi, cutoff_multi))
- return true;
- else
+
+ /*
+ * Might have to ratchet back relminmxid_nofreeze_out, which we assume
+ * won't be frozen by caller (even when we return true)
+ */
+ if (MultiXactIdPrecedes(multi, *relminmxid_nofreeze_out))
+ *relminmxid_nofreeze_out = multi;
+
+ if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
{
- MultiXactMember *members;
- int nmembers;
- int i;
-
- /* need to check whether any member of the mxact is too old */
-
- nmembers = GetMultiXactIdMembers(multi, &members, false,
- HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
-
- for (i = 0; i < nmembers; i++)
- {
- if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
- {
- pfree(members);
- return true;
- }
- }
- if (nmembers > 0)
- pfree(members);
+ /*
+ * pg_upgrade'd MultiXact doesn't need to have its XID members
+ * affect caller's relfrozenxid_nofreeze_out (just freeze it)
+ */
+ return true;
}
+ else if (MultiXactIdPrecedes(multi, limit_multi))
+ needs_freeze = true;
+
+ /*
+ * Need to check whether any member of the mxact is too old to
+ * determine if MultiXact needs to be frozen now. We even access the
+ * members when we know that the MultiXactId isn't eligible for
+ * freezing now -- we must still maintain relfrozenxid_nofreeze_out.
+ */
+ nmembers = GetMultiXactIdMembers(multi, &members, false,
+ HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
+
+ for (int i = 0; i < nmembers; i++)
+ {
+ xid = members[i].xid;
+
+ if (TransactionIdPrecedes(xid, limit_xid))
+ needs_freeze = true;
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ }
+ if (nmembers > 0)
+ pfree(members);
}
else
{
xid = HeapTupleHeaderGetRawXmax(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ if (TransactionIdPrecedes(xid, limit_xid))
+ needs_freeze = true;
+ }
}
if (tuple->t_infomask & HEAP_MOVED)
{
xid = HeapTupleHeaderGetXvac(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ if (TransactionIdPrecedes(xid, limit_xid))
+ needs_freeze = true;
+ }
}
- return false;
+ return needs_freeze;
}
/*
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 87ab7775a..ae280d4f9 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -144,7 +144,7 @@ typedef struct LVRelState
Relation *indrels;
int nindexes;
- /* Aggressive VACUUM (scan all unfrozen pages)? */
+ /* Aggressive VACUUM? (must set relfrozenxid >= FreezeLimit) */
bool aggressive;
/* Use visibility map to skip? (disabled by DISABLE_PAGE_SKIPPING) */
bool skipwithvm;
@@ -173,8 +173,9 @@ typedef struct LVRelState
/* VACUUM operation's target cutoffs for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
- /* Are FreezeLimit/MultiXactCutoff still valid? */
- bool freeze_cutoffs_valid;
+ /* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
/* Error reporting state */
char *relnamespace;
@@ -328,6 +329,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
TransactionId OldestXmin;
+ MultiXactId OldestMxact;
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
@@ -354,17 +356,17 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* used to determine which XIDs/MultiXactIds will be frozen.
*
* If this is an aggressive VACUUM, then we're strictly required to freeze
- * any and all XIDs from before FreezeLimit, so that we will be able to
- * safely advance relfrozenxid up to FreezeLimit below (we must be able to
- * advance relminmxid up to MultiXactCutoff, too).
+ * any and all XIDs from before FreezeLimit in order to be able to advance
+ * relfrozenxid to a value >= FreezeLimit below. There is an analogous
+ * requirement around MultiXact freezing, relminmxid, and MultiXactCutoff.
*/
aggressive = vacuum_set_xid_limits(rel,
params->freeze_min_age,
params->freeze_table_age,
params->multixact_freeze_min_age,
params->multixact_freeze_table_age,
- &OldestXmin, &FreezeLimit,
- &MultiXactCutoff);
+ &OldestXmin, &OldestMxact,
+ &FreezeLimit, &MultiXactCutoff);
skipwithvm = true;
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
@@ -511,10 +513,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->vistest = GlobalVisTestFor(rel);
/* FreezeLimit controls XID freezing (always <= OldestXmin) */
vacrel->FreezeLimit = FreezeLimit;
- /* MultiXactCutoff controls MXID freezing */
+ /* MultiXactCutoff controls MXID freezing (always <= OldestMxact) */
vacrel->MultiXactCutoff = MultiXactCutoff;
- /* Track if cutoffs became invalid (possible in !aggressive case only) */
- vacrel->freeze_cutoffs_valid = true;
+ /* Initialize state used to track oldest extant XID/XMID */
+ vacrel->NewRelfrozenXid = OldestXmin;
+ vacrel->NewRelminMxid = OldestMxact;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -568,14 +571,13 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* Aggressive VACUUM must reliably advance relfrozenxid (and relminmxid).
* We are able to advance relfrozenxid in a non-aggressive VACUUM too,
* provided we didn't skip any all-visible (not all-frozen) pages using
- * the visibility map, and assuming that we didn't fail to get a cleanup
- * lock that made it unsafe with respect to FreezeLimit (or perhaps our
- * MultiXactCutoff) established for VACUUM operation.
+ * the visibility map. A non-aggressive VACUUM might advance relfrozenxid
+ * to an XID that is either older or newer than FreezeLimit (same applies
+ * to relminmxid and MultiXactCutoff).
*/
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
- !vacrel->freeze_cutoffs_valid)
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
{
- /* Cannot advance relfrozenxid/relminmxid */
+ /* Skipped an all-visible page, so cannot advance relfrozenxid */
Assert(!aggressive);
frozenxid_updated = minmulti_updated = false;
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
@@ -587,9 +589,15 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
{
Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
orig_rel_pages);
+ Assert(!aggressive ||
+ TransactionIdPrecedesOrEquals(FreezeLimit,
+ vacrel->NewRelfrozenXid));
+ Assert(!aggressive ||
+ MultiXactIdPrecedesOrEquals(MultiXactCutoff,
+ vacrel->NewRelminMxid));
vac_update_relstats(rel, new_rel_pages, new_live_tuples,
new_rel_allvisible, vacrel->nindexes > 0,
- FreezeLimit, MultiXactCutoff,
+ vacrel->NewRelfrozenXid, vacrel->NewRelminMxid,
&frozenxid_updated, &minmulti_updated, false);
}
@@ -694,17 +702,19 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
OldestXmin, diff);
if (frozenxid_updated)
{
- diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
+ diff = (int32) (vacrel->NewRelfrozenXid - vacrel->relfrozenxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relfrozenxid: %u, which is %d xids ahead of previous value\n"),
- FreezeLimit, diff);
+ vacrel->NewRelfrozenXid, diff);
}
if (minmulti_updated)
{
- diff = (int32) (MultiXactCutoff - vacrel->relminmxid);
+ diff = (int32) (vacrel->NewRelminMxid - vacrel->relminmxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relminmxid: %u, which is %d mxids ahead of previous value\n"),
- MultiXactCutoff, diff);
+ vacrel->NewRelminMxid, diff);
}
if (orig_rel_pages > 0)
{
@@ -896,8 +906,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
* find them. But even when aggressive *is* set, it's still OK if we miss
* a page whose all-frozen marking has just been cleared. Any new XIDs
* just added to that page are necessarily >= vacrel->OldestXmin, and so
- * they'll have no effect on the value to which we can safely set
- * relfrozenxid. A similar argument applies for MXIDs and relminmxid.
+ * they cannot invalidate NewRelfrozenXid tracking. A similar argument
+ * applies for NewRelminMxid tracking and OldestMxact.
*/
next_unskippable_block = 0;
if (vacrel->skipwithvm)
@@ -1584,6 +1594,8 @@ lazy_scan_prune(LVRelState *vacrel,
recently_dead_tuples;
int nnewlpdead;
int nfrozen;
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
@@ -1593,7 +1605,9 @@ lazy_scan_prune(LVRelState *vacrel,
retry:
- /* Initialize (or reset) page-level counters */
+ /* Initialize (or reset) page-level state */
+ NewRelfrozenXid = vacrel->NewRelfrozenXid;
+ NewRelminMxid = vacrel->NewRelminMxid;
tuples_deleted = 0;
lpdead_items = 0;
live_tuples = 0;
@@ -1801,7 +1815,8 @@ retry:
vacrel->FreezeLimit,
vacrel->MultiXactCutoff,
&frozen[nfrozen],
- &tuple_totally_frozen))
+ &tuple_totally_frozen,
+ &NewRelfrozenXid, &NewRelminMxid))
{
/* Will execute freeze below */
frozen[nfrozen++].offset = offnum;
@@ -1815,13 +1830,16 @@ retry:
prunestate->all_frozen = false;
}
+ vacrel->offnum = InvalidOffsetNumber;
+
/*
* We have now divided every item on the page into either an LP_DEAD item
* that will need to be vacuumed in indexes later, or a LP_NORMAL tuple
* that remains and needs to be considered for freezing now (LP_UNUSED and
* LP_REDIRECT items also remain, but are of no further interest to us).
*/
- vacrel->offnum = InvalidOffsetNumber;
+ vacrel->NewRelfrozenXid = NewRelfrozenXid;
+ vacrel->NewRelminMxid = NewRelminMxid;
/*
* Consider the need to freeze any items with tuple storage from the page
@@ -1972,6 +1990,8 @@ lazy_scan_noprune(LVRelState *vacrel,
missed_dead_tuples;
HeapTupleHeader tupleheader;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
+ TransactionId NoFreezeNewRelfrozenXid = vacrel->NewRelfrozenXid;
+ MultiXactId NoFreezeNewRelminMxid = vacrel->NewRelminMxid;
Assert(BufferGetBlockNumber(buf) == blkno);
@@ -2017,20 +2037,40 @@ lazy_scan_noprune(LVRelState *vacrel,
tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
if (heap_tuple_needs_freeze(tupleheader,
vacrel->FreezeLimit,
- vacrel->MultiXactCutoff))
+ vacrel->MultiXactCutoff,
+ &NoFreezeNewRelfrozenXid,
+ &NoFreezeNewRelminMxid))
{
if (vacrel->aggressive)
{
- /* Going to have to get cleanup lock for lazy_scan_prune */
+ /*
+ * heap_tuple_needs_freeze determined that it isn't going to
+ * be possible for the ongoing aggressive VACUUM operation to
+ * advance relfrozenxid to a value >= FreezeLimit without
+ * freezing one or more tuples with older XIDs from this page.
+ * (Or perhaps the issue was that MultiXactCutoff could not be
+ * respected. Might have even been both cutoffs, together.)
+ *
+ * Tell caller that it must acquire a full cleanup lock. It's
+ * possible that caller will have to wait a while for one, but
+ * that can't be helped -- full processing by lazy_scan_prune
+ * is required to freeze the older XIDs (and/or freeze older
+ * MultiXactIds).
+ */
vacrel->offnum = InvalidOffsetNumber;
return false;
}
-
- /*
- * Current non-aggressive VACUUM operation definitely won't be
- * able to advance relfrozenxid or relminmxid
- */
- vacrel->freeze_cutoffs_valid = false;
+ else
+ {
+ /*
+ * This is a non-aggressive VACUUM, which is under no strict
+ * obligation to advance relfrozenxid at all (much less to
+ * advance it to a value >= FreezeLimit). Non-aggressive
+ * VACUUM advances relfrozenxid/relminmxid on a best-effort
+ * basis. Accept an older final relfrozenxid/relminmxid value
+ * rather than waiting for a cleanup lock.
+ */
+ }
}
ItemPointerSet(&(tuple.t_self), blkno, offnum);
@@ -2079,6 +2119,16 @@ lazy_scan_noprune(LVRelState *vacrel,
vacrel->offnum = InvalidOffsetNumber;
+ /*
+ * By here we know for sure that caller can tolerate having reduced
+ * processing for this particular page. Before we return to report
+ * success, update vacrel with details of how we processed the page.
+ * (lazy_scan_prune expects a clean slate, so we have to delay these steps
+ * until here.)
+ */
+ vacrel->NewRelfrozenXid = NoFreezeNewRelfrozenXid;
+ vacrel->NewRelminMxid = NoFreezeNewRelminMxid;
+
/*
* Now save details of the LP_DEAD items from the page in vacrel (though
* only when VACUUM uses two-pass strategy)
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c
index 02a7e94bf..a7e988298 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/cluster.c
@@ -767,6 +767,7 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
TupleDesc oldTupDesc PG_USED_FOR_ASSERTS_ONLY;
TupleDesc newTupDesc PG_USED_FOR_ASSERTS_ONLY;
TransactionId OldestXmin;
+ MultiXactId oldestMxact;
TransactionId FreezeXid;
MultiXactId MultiXactCutoff;
bool use_sort;
@@ -856,8 +857,8 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
* Since we're going to rewrite the whole table anyway, there's no reason
* not to be aggressive about this.
*/
- vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0,
- &OldestXmin, &FreezeXid, &MultiXactCutoff);
+ vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0, &OldestXmin, &oldestMxact,
+ &FreezeXid, &MultiXactCutoff);
/*
* FreezeXid will become the table's new relfrozenxid, and that mustn't go
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 50a4a612e..0ae3b4506 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -945,14 +945,22 @@ get_all_vacuum_rels(int options)
* The output parameters are:
* - oldestXmin is the Xid below which tuples deleted by any xact (that
* committed) should be considered DEAD, not just RECENTLY_DEAD.
- * - freezeLimit is the Xid below which all Xids are replaced by
- * FrozenTransactionId during vacuum.
- * - multiXactCutoff is the value below which all MultiXactIds are removed
- * from Xmax.
+ * - oldestMxact is the Mxid below which MultiXacts are definitely not
+ * seen as visible by any running transaction.
+ * - freezeLimit is the Xid below which all Xids are definitely replaced by
+ * FrozenTransactionId during aggressive vacuums.
+ * - multiXactCutoff is the value below which all MultiXactIds are definitely
+ * removed from Xmax during aggressive vacuums.
*
* Return value indicates if vacuumlazy.c caller should make its VACUUM
* operation aggressive. An aggressive VACUUM must advance relfrozenxid up to
- * FreezeLimit, and relminmxid up to multiXactCutoff.
+ * FreezeLimit (at a minimum), and relminmxid up to multiXactCutoff (at a
+ * minimum).
+ *
+ * oldestXmin and oldestMxact are the most recent values that can ever be
+ * passed to vac_update_relstats() as frozenxid and minmulti arguments by our
+ * vacuumlazy.c caller later on. These values should be passed when it turns
+ * out that VACUUM will leave no unfrozen XIDs/XMIDs behind in the table.
*/
bool
vacuum_set_xid_limits(Relation rel,
@@ -961,6 +969,7 @@ vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff)
{
@@ -969,7 +978,6 @@ vacuum_set_xid_limits(Relation rel,
int effective_multixact_freeze_max_age;
TransactionId limit;
TransactionId safeLimit;
- MultiXactId oldestMxact;
MultiXactId mxactLimit;
MultiXactId safeMxactLimit;
int freezetable;
@@ -1065,9 +1073,11 @@ vacuum_set_xid_limits(Relation rel,
effective_multixact_freeze_max_age / 2);
Assert(mxid_freezemin >= 0);
+ /* Remember for caller */
+ *oldestMxact = GetOldestMultiXactId();
+
/* compute the cutoff multi, being careful to generate a valid value */
- oldestMxact = GetOldestMultiXactId();
- mxactLimit = oldestMxact - mxid_freezemin;
+ mxactLimit = *oldestMxact - mxid_freezemin;
if (mxactLimit < FirstMultiXactId)
mxactLimit = FirstMultiXactId;
@@ -1082,8 +1092,8 @@ vacuum_set_xid_limits(Relation rel,
(errmsg("oldest multixact is far in the past"),
errhint("Close open transactions with multixacts soon to avoid wraparound problems.")));
/* Use the safe limit, unless an older mxact is still running */
- if (MultiXactIdPrecedes(oldestMxact, safeMxactLimit))
- mxactLimit = oldestMxact;
+ if (MultiXactIdPrecedes(*oldestMxact, safeMxactLimit))
+ mxactLimit = *oldestMxact;
else
mxactLimit = safeMxactLimit;
}
@@ -1390,14 +1400,10 @@ vac_update_relstats(Relation relation,
* Update relfrozenxid, unless caller passed InvalidTransactionId
* indicating it has no new data.
*
- * Ordinarily, we don't let relfrozenxid go backwards: if things are
- * working correctly, the only way the new frozenxid could be older would
- * be if a previous VACUUM was done with a tighter freeze_min_age, in
- * which case we don't want to forget the work it already did. However,
- * if the stored relfrozenxid is "in the future", then it must be corrupt
- * and it seems best to overwrite it with the cutoff we used this time.
- * This should match vac_update_datfrozenxid() concerning what we consider
- * to be "in the future".
+ * Ordinarily, we don't let relfrozenxid go backwards. However, if the
+ * stored relfrozenxid is "in the future", then it must be corrupt, so
+ * just overwrite it. This should match vac_update_datfrozenxid()
+ * concerning what we consider to be "in the future".
*/
if (frozenxid_updated)
*frozenxid_updated = false;
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 36f975b1e..6a02d0fa8 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -563,9 +563,11 @@
statistics in the system tables <structname>pg_class</structname> and
<structname>pg_database</structname>. In particular,
the <structfield>relfrozenxid</structfield> column of a table's
- <structname>pg_class</structname> row contains the freeze cutoff XID that was used
- by the last aggressive <command>VACUUM</command> for that table. All rows
- inserted by transactions with XIDs older than this cutoff XID are
+ <structname>pg_class</structname> row contains the oldest
+ remaining XID at the end of the most recent <command>VACUUM</command>
+ that successfully advanced <structfield>relfrozenxid</structfield>
+ (typically the most recent aggressive VACUUM). All rows inserted
+ by transactions with XIDs older than this cutoff XID are
guaranteed to have been frozen. Similarly,
the <structfield>datfrozenxid</structfield> column of a database's
<structname>pg_database</structname> row is a lower bound on the unfrozen XIDs
@@ -588,6 +590,17 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
cutoff XID to the current transaction's XID.
</para>
+ <tip>
+ <para>
+ <literal>VACUUM VERBOSE</literal> outputs information about
+ <structfield>relfrozenxid</structfield> and/or
+ <structfield>relminmxid</structfield> when either field was
+ advanced. The same details appear in the server log when <xref
+ linkend="guc-log-autovacuum-min-duration"/> reports on vacuuming
+ by autovacuum.
+ </para>
+ </tip>
+
<para>
<command>VACUUM</command> normally only scans pages that have been modified
since the last vacuum, but <structfield>relfrozenxid</structfield> can only be
@@ -602,7 +615,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
set <literal>age(relfrozenxid)</literal> to a value just a little more than the
<varname>vacuum_freeze_min_age</varname> setting
that was used (more by the number of transactions started since the
- <command>VACUUM</command> started). If no <structfield>relfrozenxid</structfield>-advancing
+ <command>VACUUM</command> started). <command>VACUUM</command>
+ will set <structfield>relfrozenxid</structfield> to the oldest XID
+ that remains in the table, so it's possible that the final value
+ will be much more recent than strictly required.
+ If no <structfield>relfrozenxid</structfield>-advancing
<command>VACUUM</command> is issued on the table until
<varname>autovacuum_freeze_max_age</varname> is reached, an autovacuum will soon
be forced for the table.
@@ -689,8 +706,9 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
</para>
<para>
- Aggressive <command>VACUUM</command> scans, regardless of
- what causes them, enable advancing the value for that table.
+ Aggressive <command>VACUUM</command> scans, regardless of what
+ causes them, are <emphasis>guaranteed</emphasis> to be able to
+ advance the table's <structfield>relminmxid</structfield>.
Eventually, as all tables in all databases are scanned and their
oldest multixact values are advanced, on-disk storage for older
multixacts can be removed.
diff --git a/src/test/isolation/expected/vacuum-no-cleanup-lock.out b/src/test/isolation/expected/vacuum-no-cleanup-lock.out
new file mode 100644
index 000000000..9b77bb5b4
--- /dev/null
+++ b/src/test/isolation/expected/vacuum-no-cleanup-lock.out
@@ -0,0 +1,188 @@
+Parsed test spec with 4 sessions
+
+starting permutation: vacuumer_pg_class_stats dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+
+starting permutation: vacuumer_pg_class_stats dml_insert pinholder_cursor vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: vacuumer_pg_class_stats pinholder_cursor dml_insert dml_delete dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step dml_delete:
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: vacuumer_pg_class_stats dml_insert dml_delete pinholder_cursor dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step dml_delete:
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: dml_begin dml_other_begin dml_key_share dml_other_key_share vacuumer_nonaggressive_vacuum pinholder_cursor dml_commit dml_other_commit vacuumer_nonaggressive_vacuum pinholder_commit vacuumer_nonaggressive_vacuum
+step dml_begin: BEGIN;
+step dml_other_begin: BEGIN;
+step dml_key_share: SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE;
+id
+--
+ 3
+(1 row)
+
+step dml_other_key_share: SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE;
+id
+--
+ 3
+(1 row)
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_commit: COMMIT;
+step dml_other_commit: COMMIT;
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step pinholder_commit:
+ COMMIT;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
diff --git a/src/test/isolation/expected/vacuum-reltuples.out b/src/test/isolation/expected/vacuum-reltuples.out
deleted file mode 100644
index ce55376e7..000000000
--- a/src/test/isolation/expected/vacuum-reltuples.out
+++ /dev/null
@@ -1,67 +0,0 @@
-Parsed test spec with 2 sessions
-
-starting permutation: modify vac stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step vac:
- vacuum smalltbl;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
-
-starting permutation: modify open fetch1 vac close stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step open:
- begin;
- declare c1 cursor for select 1 as dummy from smalltbl;
-
-step fetch1:
- fetch next from c1;
-
-dummy
------
- 1
-(1 row)
-
-step vac:
- vacuum smalltbl;
-
-step close:
- commit;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
-
-starting permutation: modify vac stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step vac:
- vacuum smalltbl;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
diff --git a/src/test/isolation/isolation_schedule b/src/test/isolation/isolation_schedule
index 0dae483e8..06436cf46 100644
--- a/src/test/isolation/isolation_schedule
+++ b/src/test/isolation/isolation_schedule
@@ -80,7 +80,7 @@ test: alter-table-4
test: create-trigger
test: sequence-ddl
test: async-notify
-test: vacuum-reltuples
+test: vacuum-no-cleanup-lock
test: timeouts
test: vacuum-concurrent-drop
test: vacuum-conflict
diff --git a/src/test/isolation/specs/vacuum-no-cleanup-lock.spec b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec
new file mode 100644
index 000000000..991738247
--- /dev/null
+++ b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec
@@ -0,0 +1,145 @@
+# Test for vacuum's reduced processing of heap pages (used for any heap page
+# where a cleanup lock isn't immediately available)
+#
+# Debugging tip: Change VACUUM to VACUUM VERBOSE to get feedback on what's
+# really going on
+setup
+{
+ CREATE TABLE smalltbl AS SELECT i AS id FROM generate_series(1,20) i;
+ ALTER TABLE smalltbl SET (autovacuum_enabled = off);
+}
+setup
+{
+ VACUUM ANALYZE smalltbl;
+}
+
+teardown
+{
+ DROP TABLE smalltbl;
+}
+
+# This session holds a pin on smalltbl's only heap page:
+session pinholder
+step pinholder_cursor
+{
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+}
+step pinholder_commit
+{
+ COMMIT;
+}
+
+# This session inserts and deletes tuples, potentially affecting reltuples:
+session dml
+step dml_insert
+{
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+}
+step dml_delete
+{
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+}
+step dml_begin { BEGIN; }
+step dml_key_share { SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; }
+step dml_commit { COMMIT; }
+
+# Needed for Multixact test:
+session dml_other
+step dml_other_begin { BEGIN; }
+step dml_other_key_share { SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; }
+step dml_other_commit { COMMIT; }
+
+# This session runs non-aggressive VACUUM, but with maximally aggressive
+# cutoffs for tuple freezing (e.g., FreezeLimit == OldestXmin):
+session vacuumer
+setup
+{
+ SET vacuum_freeze_min_age = 0;
+ SET vacuum_multixact_freeze_min_age = 0;
+}
+step vacuumer_nonaggressive_vacuum
+{
+ VACUUM smalltbl;
+}
+step vacuumer_pg_class_stats
+{
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+}
+
+# Test VACUUM's reltuples counting mechanism.
+#
+# Final pg_class.reltuples should never be affected by VACUUM's inability to
+# get a cleanup lock on any page, except to the extent that any cleanup lock
+# contention changes the number of tuples that remain ("missed dead" tuples
+# are counted in reltuples, much like "recently dead" tuples).
+
+# Easy case:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ vacuumer_pg_class_stats # End with 21 tuples
+
+# Harder case -- count 21 tuples at the end (like last time), but with cleanup
+# lock contention this time:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ pinholder_cursor
+ vacuumer_nonaggressive_vacuum
+ vacuumer_pg_class_stats # End with 21 tuples
+ pinholder_commit # order doesn't matter
+
+# Same as "harder case", but vary the order, and delete an inserted row:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ pinholder_cursor
+ dml_insert
+ dml_delete
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ # reltuples is 21 here again -- "recently dead" tuple won't be included in
+ # count here:
+ vacuumer_pg_class_stats
+ pinholder_commit # order doesn't matter
+
+# Same as "harder case", but initial insert and delete before cursor:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ dml_delete
+ pinholder_cursor
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ # reltuples is 21 here again -- "missed dead" tuple ("recently dead" when
+ # concurrent activity held back VACUUM's OldestXmin) won't be included in
+ # count here:
+ vacuumer_pg_class_stats
+ pinholder_commit # order doesn't matter
+
+# Test VACUUM's mechanism for skipping MultiXact freezing.
+#
+# This provides test coverage for code paths that are only hit when we need to
+# freeze, but inability to acquire a cleanup lock on a heap page makes
+# freezing some XIDs/XMIDs < FreezeLimit/MultiXactCutoff impossible (without
+# waiting for a cleanup lock, which non-aggressive VACUUM is unwilling to do).
+permutation
+ dml_begin
+ dml_other_begin
+ dml_key_share
+ dml_other_key_share
+ # Will get cleanup lock, can't advance relminmxid yet:
+ # (though will usually advance relfrozenxid by ~2 XIDs)
+ vacuumer_nonaggressive_vacuum
+ pinholder_cursor
+ dml_commit
+ dml_other_commit
+ # Can't cleanup lock, so still can't advance relminmxid here:
+ # (relfrozenxid held back by XIDs in MultiXact too)
+ vacuumer_nonaggressive_vacuum
+ pinholder_commit
+ # Pin was dropped, so will advance relminmxid, at long last:
+ # (ditto for relfrozenxid advancement)
+ vacuumer_nonaggressive_vacuum
diff --git a/src/test/isolation/specs/vacuum-reltuples.spec b/src/test/isolation/specs/vacuum-reltuples.spec
deleted file mode 100644
index a2a461f2f..000000000
--- a/src/test/isolation/specs/vacuum-reltuples.spec
+++ /dev/null
@@ -1,49 +0,0 @@
-# Test for vacuum's handling of reltuples when pages are skipped due
-# to page pins. We absolutely need to avoid setting reltuples=0 in
-# such cases, since that interferes badly with planning.
-#
-# Expected result for all three permutation is 21 tuples, including
-# the second permutation. VACUUM is able to count the concurrently
-# inserted tuple in its final reltuples, even when a cleanup lock
-# cannot be acquired on the affected heap page.
-
-setup {
- create table smalltbl
- as select i as id from generate_series(1,20) i;
- alter table smalltbl set (autovacuum_enabled = off);
-}
-setup {
- vacuum analyze smalltbl;
-}
-
-teardown {
- drop table smalltbl;
-}
-
-session worker
-step open {
- begin;
- declare c1 cursor for select 1 as dummy from smalltbl;
-}
-step fetch1 {
- fetch next from c1;
-}
-step close {
- commit;
-}
-step stats {
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-}
-
-session vacuumer
-step vac {
- vacuum smalltbl;
-}
-step modify {
- insert into smalltbl select max(id)+1 from smalltbl;
-}
-
-permutation modify vac stats
-permutation modify open fetch1 vac close stats
-permutation modify vac stats
--
2.30.2
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-23 20:41 Robert Haas <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Robert Haas @ 2022-03-23 20:41 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 23, 2022 at 3:59 PM Peter Geoghegan <[email protected]> wrote:
> In other words, since DISABLE_PAGE_SKIPPING doesn't *consistently*
> force lazy_scan_noprune to refuse to process a page on HEAD (it all
> depends on FreezeLimit/vacuum_freeze_min_age), it is logical for
> DISABLE_PAGE_SKIPPING to totally get out of the business of caring
> about that -- better to limit it to caring only about the visibility
> map (by no longer making it force aggressiveness).
It seems to me that if DISABLE_PAGE_SKIPPING doesn't completely
disable skipping pages, we have a problem.
The option isn't named CARE_ABOUT_VISIBILITY_MAP. It's named
DISABLE_PAGE_SKIPPING.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-23 20:49 Peter Geoghegan <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-23 20:49 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 23, 2022 at 1:41 PM Robert Haas <[email protected]> wrote:
> It seems to me that if DISABLE_PAGE_SKIPPING doesn't completely
> disable skipping pages, we have a problem.
It depends on how you define skipping. DISABLE_PAGE_SKIPPING was
created at a time when a broader definition of skipping made a lot
more sense.
> The option isn't named CARE_ABOUT_VISIBILITY_MAP. It's named
> DISABLE_PAGE_SKIPPING.
VACUUM(DISABLE_PAGE_SKIPPING, VERBOSE) will still consistently show
that 100% of all of the pages from rel_pages are scanned. A page that
is "skipped" by lazy_scan_noprune isn't pruned, and won't have any of
its tuples frozen. But every other aspect of processing the page
happens in just the same way as it would in the cleanup
lock/lazy_scan_prune path.
We'll even still VACUUM the page if it happens to have some existing
LP_DEAD items left behind by opportunistic pruning. We don't need a
cleanup in either lazy_scan_noprune (a share lock is all we need), nor
do we even need one in lazy_vacuum_heap_page (a regular exclusive lock
is all we need).
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-23 20:53 Robert Haas <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Robert Haas @ 2022-03-23 20:53 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 23, 2022 at 4:49 PM Peter Geoghegan <[email protected]> wrote:
> On Wed, Mar 23, 2022 at 1:41 PM Robert Haas <[email protected]> wrote:
> > It seems to me that if DISABLE_PAGE_SKIPPING doesn't completely
> > disable skipping pages, we have a problem.
>
> It depends on how you define skipping. DISABLE_PAGE_SKIPPING was
> created at a time when a broader definition of skipping made a lot
> more sense.
>
> > The option isn't named CARE_ABOUT_VISIBILITY_MAP. It's named
> > DISABLE_PAGE_SKIPPING.
>
> VACUUM(DISABLE_PAGE_SKIPPING, VERBOSE) will still consistently show
> that 100% of all of the pages from rel_pages are scanned. A page that
> is "skipped" by lazy_scan_noprune isn't pruned, and won't have any of
> its tuples frozen. But every other aspect of processing the page
> happens in just the same way as it would in the cleanup
> lock/lazy_scan_prune path.
I see what you mean about it depending on how you define "skipping".
But I think that DISABLE_PAGE_SKIPPING is intended as a sort of
emergency safeguard when you really, really don't want to leave
anything out. And therefore I favor defining it to mean that we don't
skip any work at all.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-23 20:58 Peter Geoghegan <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-23 20:58 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 23, 2022 at 1:53 PM Robert Haas <[email protected]> wrote:
> I see what you mean about it depending on how you define "skipping".
> But I think that DISABLE_PAGE_SKIPPING is intended as a sort of
> emergency safeguard when you really, really don't want to leave
> anything out.
I agree.
> And therefore I favor defining it to mean that we don't
> skip any work at all.
But even today DISABLE_PAGE_SKIPPING won't do pruning when we cannot
acquire a cleanup lock on a page, unless it happens to have XIDs from
before FreezeLimit (which is probably 50 million XIDs behind
OldestXmin, the vacuum_freeze_min_age default). I don't see much
difference.
Anyway, this isn't important. I'll just drop the third patch.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-23 21:02 Thomas Munro <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Thomas Munro @ 2022-03-23 21:02 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Robert Haas <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 24, 2022 at 9:59 AM Peter Geoghegan <[email protected]> wrote:
> On Wed, Mar 23, 2022 at 1:53 PM Robert Haas <[email protected]> wrote:
> > And therefore I favor defining it to mean that we don't
> > skip any work at all.
>
> But even today DISABLE_PAGE_SKIPPING won't do pruning when we cannot
> acquire a cleanup lock on a page, unless it happens to have XIDs from
> before FreezeLimit (which is probably 50 million XIDs behind
> OldestXmin, the vacuum_freeze_min_age default). I don't see much
> difference.
Yeah, I found it confusing that DISABLE_PAGE_SKIPPING doesn't disable
all page skipping, so 3414099c turned out to be not enough.
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-23 22:28 Peter Geoghegan <[email protected]>
parent: Thomas Munro <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-23 22:28 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Robert Haas <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 23, 2022 at 2:03 PM Thomas Munro <[email protected]> wrote:
> Yeah, I found it confusing that DISABLE_PAGE_SKIPPING doesn't disable
> all page skipping, so 3414099c turned out to be not enough.
The proposed change to DISABLE_PAGE_SKIPPING is partly driven by that,
and partly driven by a similar concern about aggressive VACUUM.
It seems worth emphasizing the idea that an aggressive VACUUM is now
just the same as any other VACUUM except for one detail: we're
guaranteed to advance relfrozenxid to a value >= FreezeLimit at the
end. The non-aggressive case has the choice to do things that make
that impossible. But there are only two places where this can happen now:
1. Non-aggressive VACUUMs might decide to skip some all-visible pages in
the new lazy_scan_skip() helper routine for skipping with the VM (see
v11-0002-*).
2. A non-aggressive VACUUM can *always* decide to ratchet back its
target relfrozenxid in lazy_scan_noprune, to avoid waiting for a
cleanup lock -- a final value from before FreezeLimit is usually still
pretty good.
The first scenario is the only one where it becomes impossible for
non-aggressive VACUUM to be able to advance relfrozenxid (with
v11-0001-* in place) by any amount. Even that's a choice, made by
weighing costs against benefits.
There is no behavioral change in v11-0002-* (we're still using the
old SKIP_PAGES_THRESHOLD strategy), but the lazy_scan_skip()
helper routine could fairly easily be taught a lot more about the
downside of skipping all-visible pages (namely how that makes it
impossible to advance relfrozenxid).
Maybe it's worth skipping all-visible pages (there are lots of them
and age(relfrozenxid) is still low), and maybe it isn't worth it. We
should get to decide, without implementation details making
relfrozenxid advancement unsafe.
It would be great if you could take a look v11-0002-*, Robert. Does it
make sense to you?
Thanks
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-24 17:20 Robert Haas <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Robert Haas @ 2022-03-24 17:20 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 23, 2022 at 6:28 PM Peter Geoghegan <[email protected]> wrote:
> It would be great if you could take a look v11-0002-*, Robert. Does it
> make sense to you?
You're probably not going to love hearing this, but I think you're
still explaining things here in ways that are too baroque and hard to
follow. I do think it's probably better. But, for example, in the
commit message for 0001, I think you could change the subject line to
"Allow non-aggressive vacuums to advance relfrozenxid" and it would be
clearer. And then I think you could eliminate about half of the first
paragraph, starting with "There is no fixed relationship", and all of
the third paragraph (which starts with "Later work..."), and I think
removing all that material would make it strictly more clear than it
is currently. I don't think it's the place of a commit message to
speculate too much on future directions or to wax eloquent on
theoretical points. If that belongs anywhere, it's in a mailing list
discussion.
It seems to me that 0002 mixes code movement with functional changes.
I'm completely on board with moving the code that decides how much to
skip into a function. That seems like a great idea, and probably
overdue. But it is not easy for me to see what has changed
functionally between the old and new code organization, and I bet it
would be possible to split this into two patches, one of which creates
a function, and the other of which fixes the problem, and I think that
would be a useful service to future readers of the code. I have a hard
time believing that if someone in the future bisects a problem back to
this commit, they're going to have an easy time finding the behavior
change in here. In fact I can't see it myself. I think the actual
functional change is to fix what is described in the second paragraph
of the commit message, but I haven't been able to figure out where the
logic is actually changing to address that. Note that I would be happy
with the behavior change happening either before or after the code
reorganization.
I also think that the commit message for 0002 is probably longer and
more complex than is really helpful, and that the subject line is too
vague, but since I don't yet understand exactly what's happening here,
I cannot comment on how I think it should be revised at this point,
except to say that the second paragraph of that commit message looks
like the most useful part.
I would also like to mention a few things that I do like about 0002.
One is that it seems to collapse two different pieces of logic for
page skipping into one. That seems good. As mentioned, it's especially
good because that logic is abstracted into a function. Also, it looks
like it is making a pretty localized change to one (1) aspect of what
VACUUM does -- and I definitely prefer patches that change only one
thing at a time.
Hope that's helpful.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-24 19:28 Peter Geoghegan <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-24 19:28 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 24, 2022 at 10:21 AM Robert Haas <[email protected]> wrote:
> You're probably not going to love hearing this, but I think you're
> still explaining things here in ways that are too baroque and hard to
> follow. I do think it's probably better.
There are a lot of dimensions to this work. It's hard to know which to
emphasize here.
> But, for example, in the
> commit message for 0001, I think you could change the subject line to
> "Allow non-aggressive vacuums to advance relfrozenxid" and it would be
> clearer.
But non-aggressive VACUUMs have always been able to do that.
How about: "Set relfrozenxid to oldest extant XID seen by VACUUM"
> And then I think you could eliminate about half of the first
> paragraph, starting with "There is no fixed relationship", and all of
> the third paragraph (which starts with "Later work..."), and I think
> removing all that material would make it strictly more clear than it
> is currently. I don't think it's the place of a commit message to
> speculate too much on future directions or to wax eloquent on
> theoretical points. If that belongs anywhere, it's in a mailing list
> discussion.
Okay, I'll do that.
> It seems to me that 0002 mixes code movement with functional changes.
Believe it or not, I avoided functional changes in 0002 -- at least in
one important sense. That's why you had difficulty spotting any. This
must sound peculiar, since the commit message very clearly says that
the commit avoids a problem seen only in the non-aggressive case. It's
really quite subtle.
You wrote this comment and code block (which I propose to remove in
0002), so clearly you already understand the race condition that I'm
concerned with here:
- if (skipping_blocks && blkno < rel_pages - 1)
- {
- /*
- * Tricky, tricky. If this is in aggressive vacuum, the page
- * must have been all-frozen at the time we checked whether it
- * was skippable, but it might not be any more. We must be
- * careful to count it as a skipped all-frozen page in that
- * case, or else we'll think we can't update relfrozenxid and
- * relminmxid. If it's not an aggressive vacuum, we don't
- * know whether it was initially all-frozen, so we have to
- * recheck.
- */
- if (vacrel->aggressive ||
- VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
- vacrel->frozenskipped_pages++;
- continue;
- }
What you're saying here boils down to this: it doesn't matter what the
visibility map would say right this microsecond (in the aggressive
case) were we to call VM_ALL_FROZEN(): we know for sure that the VM
said that this page was all-frozen *in the recent past*. That's good
enough; we will never fail to scan a page that might have an XID <
OldestXmin (ditto for XMIDs) this way, which is all that really
matters.
This is absolutely mandatory in the aggressive case, because otherwise
relfrozenxid advancement might be seen as unsafe. My observation is:
Why should we accept the same race in the non-aggressive case? Why not
do essentially the same thing in every VACUUM?
In 0002 we now track if each range that we actually chose to skip had
any all-visible (not all-frozen) pages -- if that happens then
relfrozenxid advancement becomes unsafe. The existing code uses
"vacrel->aggressive" as a proxy for the same condition -- the existing
code reasons based on what the visibility map must have said about the
page in the recent past. Which makes sense, but only works in the
aggressive case. The approach taken in 0002 also makes the code
simpler, which is what enabled putting the VM skipping code into its
own helper function, but that was just a bonus.
And so you could almost say that there is now behavioral change at
all. We're skipping pages in the same way, based on the same
information (from the visibility map) as before. We're just being a
bit more careful than before about how that information is tracked, to
avoid this race. A race that we always avoided in the aggressive case
is now consistently avoided.
> I'm completely on board with moving the code that decides how much to
> skip into a function. That seems like a great idea, and probably
> overdue. But it is not easy for me to see what has changed
> functionally between the old and new code organization, and I bet it
> would be possible to split this into two patches, one of which creates
> a function, and the other of which fixes the problem, and I think that
> would be a useful service to future readers of the code.
It seems kinda tricky to split up 0002 like that. It's possible, but
I'm not sure if it's possible to split it in a way that highlights the
issue that I just described. Because we already avoided the race in
the aggressive case.
> I also think that the commit message for 0002 is probably longer and
> more complex than is really helpful, and that the subject line is too
> vague, but since I don't yet understand exactly what's happening here,
> I cannot comment on how I think it should be revised at this point,
> except to say that the second paragraph of that commit message looks
> like the most useful part.
I'll work on that.
> I would also like to mention a few things that I do like about 0002.
> One is that it seems to collapse two different pieces of logic for
> page skipping into one. That seems good. As mentioned, it's especially
> good because that logic is abstracted into a function. Also, it looks
> like it is making a pretty localized change to one (1) aspect of what
> VACUUM does -- and I definitely prefer patches that change only one
> thing at a time.
Totally embracing the idea that we don't necessarily need very recent
information from the visibility map (it just has to be after
OldestXmin was established) has a lot of advantages, architecturally.
It could in principle be hours out of date in the longest VACUUM
operations -- that should be fine. This is exactly the same principle
that makes it okay to stick with our original rel_pages, even when the
table has grown during a VACUUM operation (I documented this in commit
73f6ec3d3c recently).
We could build on the approach taken by 0002 to create a totally
comprehensive picture of the ranges we're skipping up-front, before we
actually scan any pages, even with very large tables. We could in
principle cache a very large number of skippable ranges up-front,
without ever going back to the visibility map again later (unless we
need to set a bit). It really doesn't matter if somebody else unsets a
page's VM bit concurrently, at all.
I see a lot of advantage to knowing our final scanned_pages almost
immediately. Things like prefetching, capping the size of the
dead_items array more intelligently (use final scanned_pages instead
of rel_pages in dead_items_max_items()), improvements to progress
reporting...not to mention more intelligent choices about whether we
should try to advance relfrozenxid a bit earlier during non-aggressive
VACUUMs.
> Hope that's helpful.
Very helpful -- thanks!
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-24 20:21 Robert Haas <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Robert Haas @ 2022-03-24 20:21 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 24, 2022 at 3:28 PM Peter Geoghegan <[email protected]> wrote:
> But non-aggressive VACUUMs have always been able to do that.
>
> How about: "Set relfrozenxid to oldest extant XID seen by VACUUM"
Sure, that sounds nice.
> Believe it or not, I avoided functional changes in 0002 -- at least in
> one important sense. That's why you had difficulty spotting any. This
> must sound peculiar, since the commit message very clearly says that
> the commit avoids a problem seen only in the non-aggressive case. It's
> really quite subtle.
Well, I think the goal in revising the code is to be as un-subtle as
possible. Commits that people can't easily understand breed future
bugs.
> What you're saying here boils down to this: it doesn't matter what the
> visibility map would say right this microsecond (in the aggressive
> case) were we to call VM_ALL_FROZEN(): we know for sure that the VM
> said that this page was all-frozen *in the recent past*. That's good
> enough; we will never fail to scan a page that might have an XID <
> OldestXmin (ditto for XMIDs) this way, which is all that really
> matters.
Makes sense. So maybe the commit message should try to emphasize this
point e.g. "If a page is all-frozen at the time we check whether it
can be skipped, don't allow it to affect the relfrozenxmin and
relminmxid which we set for the relation. This was previously true for
aggressive vacuums, but not for non-aggressive vacuums, which was
inconsistent. (The reason this is a safe thing to do is that any new
XIDs or MXIDs that appear on the page after we initially observe it to
be frozen must be newer than any relfrozenxid or relminmxid the
current vacuum could possibly consider storing into pg_class.)"
> This is absolutely mandatory in the aggressive case, because otherwise
> relfrozenxid advancement might be seen as unsafe. My observation is:
> Why should we accept the same race in the non-aggressive case? Why not
> do essentially the same thing in every VACUUM?
Sure, that seems like a good idea. I think I basically agree with the
goals of the patch. My concern is just about making the changes
understandable to future readers. This area is notoriously subtle, and
people are going to introduce more bugs even if the comments and code
organization are fantastic.
> And so you could almost say that there is now behavioral change at
> all.
I vigorously object to this part, though. We should always err on the
side of saying that commits *do* have behavioral changes. We should go
out of our way to call out in the commit message any possible way that
someone might notice the difference between the post-commit situation
and the pre-commit situation. It is fine, even good, to also be clear
about how we're maintaining continuity and why we don't think it's a
problem, but the only commits that should be described as not having
any behavioral change are ones that do mechanical code movement, or
are just changing comments, or something like that.
> It seems kinda tricky to split up 0002 like that. It's possible, but
> I'm not sure if it's possible to split it in a way that highlights the
> issue that I just described. Because we already avoided the race in
> the aggressive case.
I do see that there are some difficulties there. I'm not sure what to
do about that. I think a sufficiently clear commit message could
possibly be enough, rather than trying to split the patch. But I also
think splitting the patch should be considered, if that can reasonably
be done.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-24 21:40 Peter Geoghegan <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-24 21:40 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 24, 2022 at 1:21 PM Robert Haas <[email protected]> wrote:
> > How about: "Set relfrozenxid to oldest extant XID seen by VACUUM"
>
> Sure, that sounds nice.
Cool.
> > What you're saying here boils down to this: it doesn't matter what the
> > visibility map would say right this microsecond (in the aggressive
> > case) were we to call VM_ALL_FROZEN(): we know for sure that the VM
> > said that this page was all-frozen *in the recent past*. That's good
> > enough; we will never fail to scan a page that might have an XID <
> > OldestXmin (ditto for XMIDs) this way, which is all that really
> > matters.
>
> Makes sense. So maybe the commit message should try to emphasize this
> point e.g. "If a page is all-frozen at the time we check whether it
> can be skipped, don't allow it to affect the relfrozenxmin and
> relminmxid which we set for the relation. This was previously true for
> aggressive vacuums, but not for non-aggressive vacuums, which was
> inconsistent. (The reason this is a safe thing to do is that any new
> XIDs or MXIDs that appear on the page after we initially observe it to
> be frozen must be newer than any relfrozenxid or relminmxid the
> current vacuum could possibly consider storing into pg_class.)"
Okay, I'll add something more like that.
Almost every aspect of relfrozenxid advancement by VACUUM seems
simpler when thought about in these terms IMV. Every VACUUM now scans
all pages that might have XIDs < OldestXmin, and so every VACUUM can
advance relfrozenxid to the oldest extant XID (barring non-aggressive
VACUUMs that *choose* to skip some all-visible pages).
There are a lot more important details, of course. My "Every
VACUUM..." statement works well as an axiom because all of those other
details don't create any awkward exceptions.
> > This is absolutely mandatory in the aggressive case, because otherwise
> > relfrozenxid advancement might be seen as unsafe. My observation is:
> > Why should we accept the same race in the non-aggressive case? Why not
> > do essentially the same thing in every VACUUM?
>
> Sure, that seems like a good idea. I think I basically agree with the
> goals of the patch.
Great.
> My concern is just about making the changes
> understandable to future readers. This area is notoriously subtle, and
> people are going to introduce more bugs even if the comments and code
> organization are fantastic.
Makes sense.
> > And so you could almost say that there is now behavioral change at
> > all.
>
> I vigorously object to this part, though. We should always err on the
> side of saying that commits *do* have behavioral changes.
I think that you've taken my words too literally here. I would never
conceal the intent of a piece of work like that. I thought that it
would clarify matters to point out that I could in theory "get away
with it if I wanted to" in this instance. This was only a means of
conveying a subtle point about the behavioral changes from 0002 --
since you couldn't initially see them yourself (even with my commit
message).
Kind of like Tom Lane's 2011 talk on the query planner. The one where
he lied to the audience several times.
> > It seems kinda tricky to split up 0002 like that. It's possible, but
> > I'm not sure if it's possible to split it in a way that highlights the
> > issue that I just described. Because we already avoided the race in
> > the aggressive case.
>
> I do see that there are some difficulties there. I'm not sure what to
> do about that. I think a sufficiently clear commit message could
> possibly be enough, rather than trying to split the patch. But I also
> think splitting the patch should be considered, if that can reasonably
> be done.
I'll see if I can come up with something. It's hard to be sure about
that kind of thing when you're this close to the code.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-28 03:24 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-28 03:24 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 24, 2022 at 2:40 PM Peter Geoghegan <[email protected]> wrote:
> > > This is absolutely mandatory in the aggressive case, because otherwise
> > > relfrozenxid advancement might be seen as unsafe. My observation is:
> > > Why should we accept the same race in the non-aggressive case? Why not
> > > do essentially the same thing in every VACUUM?
> >
> > Sure, that seems like a good idea. I think I basically agree with the
> > goals of the patch.
>
> Great.
Attached is v12. My current goal is to commit all 3 patches before
feature freeze. Note that this does not include the more complicated
patch including with previous revisions of the patch series (the
page-level freezing work that appeared in versions before v11).
Changes that appear in this new revision, v12:
* Reworking of the commit messages based on feedback from Robert.
* General cleanup of the changes to heapam.c from 0001 (the changes to
heap_prepare_freeze_tuple and related functions). New and existing
code now fits together a bit better. I also added a couple of new
documenting assertions, to make the flow a bit easier to understand.
* Added new assertions that document
OldestXmin/FreezeLimit/relfrozenxid invariants, right at the point we
update pg_class within vacuumlazy.c.
These assertions would have a decent chance of failing if there were
any bugs in the code.
* Removed patch that made DISABLE_PAGE_SKIPPING not force aggressive
VACUUM, limiting the underlying mechanism to forcing scanning of all
pages in lazy_scan_heap (v11 was the first and last revision that
included this patch).
* Adds a new small patch 0003. This just moves the last piece of
resource allocation that still took place at the top of
lazy_scan_heap() back into its caller, heap_vacuum_rel().
The work in 0003 probably should have happened as part of the patch
that became commit 73f6ec3d -- same idea. It's totally mechanical
stuff. With 0002 and 0003, there is hardly any lazy_scan_heap code
before the main loop that iterates through blocks in rel_pages (and
the code that's still there is obviously related to the loop in a
direct and obvious way). This seems like a big overall improvement in
maintainability.
Didn't see a way to split up 0002, per Robert's suggestion 3 days ago.
As I said at the time, it's possible to split it up, but not in a way
that highlights the underlying issue (since the issue 0002 fixes was
always limited to non-aggressive VACUUMs). The commit message may have
to suffice.
--
Peter Geoghegan
Attachments:
[application/octet-stream] v12-0001-Set-relfrozenxid-to-oldest-extant-XID-seen-by-VA.patch (58.3K, ../../CAH2-Wzk3fNBa_S3Ngi+16GQiyJ=AmUu3oUY99syMDTMRxitfyQ@mail.gmail.com/2-v12-0001-Set-relfrozenxid-to-oldest-extant-XID-seen-by-VA.patch)
download | inline diff:
From 8bac0453c9414f2b888cb916559d1909cd07be64 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v12 1/3] Set relfrozenxid to oldest extant XID seen by VACUUM.
When VACUUM set relfrozenxid before now, it set it to whatever value was
used to determine which tuples to freeze -- the FreezeLimit cutoff.
This approach was very naive: the relfrozenxid invariant only requires
that new relfrozenxid values be <= the oldest extant XID remaining in
the table (at the point that the VACUUM operation ends), which in
general might be much more recent than FreezeLimit.
VACUUM now sets relfrozenxid (and relminmxid) using the exact oldest
extant XID (and oldest extant MultiXactId) from the table, including
XIDs from the table's remaining/unfrozen MultiXacts. This requires that
VACUUM carefully track the oldest unfrozen XID/MultiXactId as it goes.
This optimization doesn't require any changes to the definition of
relfrozenxid, nor does it require changes to the core design of
freezing.
Final relfrozenxid values must still be >= FreezeLimit in an aggressive
VACUUM -- FreezeLimit still acts as a lower bound on the final value
that aggressive VACUUM can set relfrozenxid to. Since standard VACUUMs
still make no guarantees about advancing relfrozenxid, they might as
well set relfrozenxid to a value from well before FreezeLimit when the
opportunity presents itself. In general standard VACUUMs may now set
relfrozenxid to any value > the original relfrozenxid and <= OldestXmin.
Credit for the general idea of using the oldest extant XID to set
pg_class.relfrozenxid at the end of VACUUM goes to Andres Freund.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Andres Freund <[email protected]>
Reviewed-By: Robert Haas <[email protected]>
Discussion: https://postgr.es/m/CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com
---
src/include/access/heapam.h | 4 +-
src/include/access/heapam_xlog.h | 4 +-
src/include/commands/vacuum.h | 1 +
src/backend/access/heap/heapam.c | 306 ++++++++++++++----
src/backend/access/heap/vacuumlazy.c | 175 ++++++----
src/backend/commands/cluster.c | 5 +-
src/backend/commands/vacuum.c | 42 +--
doc/src/sgml/maintenance.sgml | 30 +-
.../expected/vacuum-no-cleanup-lock.out | 189 +++++++++++
.../isolation/expected/vacuum-reltuples.out | 67 ----
src/test/isolation/isolation_schedule | 2 +-
.../specs/vacuum-no-cleanup-lock.spec | 150 +++++++++
.../isolation/specs/vacuum-reltuples.spec | 49 ---
13 files changed, 744 insertions(+), 280 deletions(-)
create mode 100644 src/test/isolation/expected/vacuum-no-cleanup-lock.out
delete mode 100644 src/test/isolation/expected/vacuum-reltuples.out
create mode 100644 src/test/isolation/specs/vacuum-no-cleanup-lock.spec
delete mode 100644 src/test/isolation/specs/vacuum-reltuples.spec
diff --git a/src/include/access/heapam.h b/src/include/access/heapam.h
index b46ab7d73..df5b31700 100644
--- a/src/include/access/heapam.h
+++ b/src/include/access/heapam.h
@@ -168,7 +168,9 @@ extern bool heap_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi);
extern bool heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi);
+ MultiXactId cutoff_multi,
+ TransactionId *relfrozenxid_nofreeze_out,
+ MultiXactId *relminmxid_nofreeze_out);
extern bool heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple);
extern void simple_heap_insert(Relation relation, HeapTuple tup);
diff --git a/src/include/access/heapam_xlog.h b/src/include/access/heapam_xlog.h
index 5c47fdcec..2d8a7f627 100644
--- a/src/include/access/heapam_xlog.h
+++ b/src/include/access/heapam_xlog.h
@@ -410,7 +410,9 @@ extern bool heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId cutoff_xid,
TransactionId cutoff_multi,
xl_heap_freeze_tuple *frz,
- bool *totally_frozen);
+ bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out);
extern void heap_execute_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple *xlrec_tp);
extern XLogRecPtr log_heap_visible(RelFileNode rnode, Buffer heap_buffer,
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index d64f6268f..ead88edda 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -291,6 +291,7 @@ extern bool vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff);
extern bool vacuum_xid_failsafe_check(TransactionId relfrozenxid,
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 3746336a0..55670f507 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -6128,7 +6128,12 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* NB -- this might have the side-effect of creating a new MultiXactId!
*
* "flags" is an output value; it's used to tell caller what to do on return.
- * Possible flags are:
+ *
+ * "xmax_oldest_xid_out" is an output value; we must handle the details of
+ * tracking the oldest extant member Xid within any Multixact that will
+ * remain. This is one component used by caller to track relfrozenxid_out.
+ *
+ * Possible values that we can set in "flags":
* FRM_NOOP
* don't do anything -- keep existing Xmax
* FRM_INVALIDATE_XMAX
@@ -6140,12 +6145,18 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* FRM_RETURN_IS_MULTI
* The return value is a new MultiXactId to set as new Xmax.
* (caller must obtain proper infomask bits using GetMultiXactIdHintBits)
+ *
+ * Final "xmax_oldest_xid_out" value should be ignored completely unless
+ * "flags" contains either FRM_NOOP or FRM_RETURN_IS_MULTI. Final value is
+ * drawn from oldest extant Xid that will remain in some MultiXact (old or
+ * new) after xmax is processed. Xids that won't remain after processing will
+ * never affect final "xmax_oldest_xid_out" set here, per general convention.
*/
static TransactionId
FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, MultiXactId cutoff_multi,
- uint16 *flags)
+ uint16 *flags, TransactionId *xmax_oldest_xid_out)
{
TransactionId xid = InvalidTransactionId;
int i;
@@ -6157,6 +6168,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
bool has_lockers;
TransactionId update_xid;
bool update_committed;
+ TransactionId temp_xid_out;
*flags = 0;
@@ -6228,6 +6240,10 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
}
}
+ /*
+ * Don't push back xmax_oldest_xid_out using FRM_RETURN_IS_XID Xid, or
+ * when no Xids will remain
+ */
return xid;
}
@@ -6251,6 +6267,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
/* is there anything older than the cutoff? */
need_replace = false;
+ temp_xid_out = *xmax_oldest_xid_out; /* init for FRM_NOOP */
for (i = 0; i < nmembers; i++)
{
if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
@@ -6258,28 +6275,38 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
need_replace = true;
break;
}
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
}
/*
* In the simplest case, there is no member older than the cutoff; we can
- * keep the existing MultiXactId as is.
+ * keep the existing MultiXactId as-is, avoiding a more expensive second
+ * pass over the multi
*/
if (!need_replace)
{
+ /*
+ * When xmax_oldest_xid_out gets pushed back here it's likely that the
+ * update Xid was the oldest member, but we don't rely on that
+ */
*flags |= FRM_NOOP;
+ *xmax_oldest_xid_out = temp_xid_out;
pfree(members);
- return InvalidTransactionId;
+ return multi;
}
/*
- * If the multi needs to be updated, figure out which members do we need
- * to keep.
+ * Do a more thorough second pass over the multi to figure out which
+ * member XIDs actually need to be kept. Checking the precise status of
+ * individual members might even show that we don't need to keep anything.
*/
nnewmembers = 0;
newmembers = palloc(sizeof(MultiXactMember) * nmembers);
has_lockers = false;
update_xid = InvalidTransactionId;
update_committed = false;
+ temp_xid_out = *xmax_oldest_xid_out; /* init for FRM_RETURN_IS_MULTI */
for (i = 0; i < nmembers; i++)
{
@@ -6335,7 +6362,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
}
/*
- * Since the tuple wasn't marked HEAPTUPLE_DEAD by vacuum, the
+ * Since the tuple wasn't totally removed when vacuum pruned, the
* update Xid cannot possibly be older than the xid cutoff. The
* presence of such a tuple would cause corruption, so be paranoid
* and check.
@@ -6348,15 +6375,20 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
update_xid, cutoff_xid)));
/*
- * If we determined that it's an Xid corresponding to an update
- * that must be retained, additionally add it to the list of
- * members of the new Multi, in case we end up using that. (We
- * might still decide to use only an update Xid and not a multi,
- * but it's easier to maintain the list as we walk the old members
- * list.)
+ * We determined that this is an Xid corresponding to an update
+ * that must be retained -- add it to new members list for later.
+ *
+ * Also consider pushing back temp_xid_out, which is needed when
+ * we later conclude that a new multi is required (i.e. when we go
+ * on to set FRM_RETURN_IS_MULTI for our caller because we also
+ * need to retain a locker that's still running).
*/
if (TransactionIdIsValid(update_xid))
+ {
newmembers[nnewmembers++] = members[i];
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
+ }
}
else
{
@@ -6374,11 +6406,17 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
pfree(members);
+ /*
+ * Determine what to do with caller's multi based on information gathered
+ * during our second pass
+ */
if (nnewmembers == 0)
{
/* nothing worth keeping!? Tell caller to remove the whole thing */
*flags |= FRM_INVALIDATE_XMAX;
xid = InvalidTransactionId;
+
+ /* Don't push back xmax_oldest_xid_out -- no Xids will remain */
}
else if (TransactionIdIsValid(update_xid) && !has_lockers)
{
@@ -6394,6 +6432,8 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
if (update_committed)
*flags |= FRM_MARK_COMMITTED;
xid = update_xid;
+
+ /* Don't push back xmax_oldest_xid_out using FRM_RETURN_IS_XID Xid */
}
else
{
@@ -6403,6 +6443,12 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
*/
xid = MultiXactIdCreateFromMembers(nnewmembers, newmembers);
*flags |= FRM_RETURN_IS_MULTI;
+
+ /*
+ * The oldest Xid we're transferring from the old multixact over to
+ * the new one might push back xmax_oldest_xid_out
+ */
+ *xmax_oldest_xid_out = temp_xid_out;
}
pfree(newmembers);
@@ -6421,21 +6467,30 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* will be totally frozen after these operations are performed and false if
* more freezing will eventually be required.
*
+ * The *relfrozenxid_out and *relminmxid_out arguments are the current target
+ * relfrozenxid and relminmxid for VACUUM caller's heap rel. Any and all
+ * unfrozen XIDs or MXIDs that remain in caller's rel after VACUUM finishes
+ * _must_ have values >= the final relfrozenxid/relminmxid values in pg_class.
+ * This includes XIDs that remain as MultiXact members from any tuple's xmax.
+ * Each call here pushes back *relfrozenxid_out and/or *relminmxid_out as
+ * needed to avoid unsafe final values in rel's authoritative pg_class tuple.
+ *
* Caller is responsible for setting the offset field, if appropriate.
*
* It is assumed that the caller has checked the tuple with
* HeapTupleSatisfiesVacuum() and determined that it is not HEAPTUPLE_DEAD
* (else we should be removing the tuple, not freezing it).
*
- * NB: cutoff_xid *must* be <= the current global xmin, to ensure that any
+ * NB: This function has side effects: it might allocate a new MultiXactId.
+ * It will be set as tuple's new xmax when our *frz output is processed within
+ * heap_execute_freeze_tuple later on. If the tuple is in a shared buffer
+ * then caller had better have an exclusive lock on it already.
+ *
+ * NB: cutoff_xid *must* be <= VACUUM's OldestXmin, to ensure that any
* XID older than it could neither be running nor seen as running by any
* open transaction. This ensures that the replacement will not change
* anyone's idea of the tuple state.
- * Similarly, cutoff_multi must be less than or equal to the smallest
- * MultiXactId used by any transaction currently open.
- *
- * If the tuple is in a shared buffer, caller must hold an exclusive lock on
- * that buffer.
+ * Similarly, cutoff_multi must be <= VACUUM's OldestMxact.
*
* NB: It is not enough to set hint bits to indicate something is
* committed/invalid -- they might not be set on a standby, or after crash
@@ -6445,7 +6500,9 @@ bool
heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi,
- xl_heap_freeze_tuple *frz, bool *totally_frozen)
+ xl_heap_freeze_tuple *frz, bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out)
{
bool changed = false;
bool xmax_already_frozen = false;
@@ -6464,7 +6521,9 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* already a permanent value), while in the block below it is set true to
* mean "xmin won't need freezing after what we do to it here" (false
* otherwise). In both cases we're allowed to set totally_frozen, as far
- * as xmin is concerned.
+ * as xmin is concerned. Both cases also don't require relfrozenxid_out
+ * handling, since either way the tuple's xmin will be a permanent value
+ * once we're done with it.
*/
xid = HeapTupleHeaderGetXmin(tuple);
if (!TransactionIdIsNormal(xid))
@@ -6489,6 +6548,12 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
frz->t_infomask |= HEAP_XMIN_FROZEN;
changed = true;
}
+ else
+ {
+ /* xmin to remain unfrozen. Could push back relfrozenxid_out. */
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ }
}
/*
@@ -6506,15 +6571,29 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
{
TransactionId newxmax;
uint16 flags;
+ TransactionId xmax_oldest_xid_out = *relfrozenxid_out;
newxmax = FreezeMultiXactId(xid, tuple->t_infomask,
relfrozenxid, relminmxid,
- cutoff_xid, cutoff_multi, &flags);
+ cutoff_xid, cutoff_multi,
+ &flags, &xmax_oldest_xid_out);
freeze_xmax = (flags & FRM_INVALIDATE_XMAX);
if (flags & FRM_RETURN_IS_XID)
{
+ /*
+ * xmax will become an updater Xid (original MultiXact's updater
+ * member Xid will be carried forward as a simple Xid in Xmax).
+ * Might have to ratchet back relfrozenxid_out here, though never
+ * relminmxid_out.
+ */
+ Assert(!freeze_xmax);
+ Assert(TransactionIdIsValid(newxmax));
+ if (TransactionIdPrecedes(newxmax, *relfrozenxid_out))
+ *relfrozenxid_out = newxmax;
+ /* Note: xmax_oldest_xid_out isn't valid here */
+
/*
* NB -- some of these transformations are only valid because we
* know the return Xid is a tuple updater (i.e. not merely a
@@ -6533,6 +6612,19 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
uint16 newbits;
uint16 newbits2;
+ /*
+ * xmax is an old MultiXactId which we have to replace with a new
+ * Multixact, that carries forward some of the original's Xids.
+ * Might have to ratchet back relfrozenxid_out here, though never
+ * relminmxid_out.
+ */
+ Assert(!freeze_xmax);
+ Assert(MultiXactIdIsValid(newxmax));
+ Assert(!MultiXactIdPrecedes(newxmax, *relminmxid_out));
+ Assert(TransactionIdPrecedesOrEquals(xmax_oldest_xid_out,
+ *relfrozenxid_out));
+ *relfrozenxid_out = xmax_oldest_xid_out;
+
/*
* We can't use GetMultiXactIdHintBits directly on the new multi
* here; that routine initializes the masks to all zeroes, which
@@ -6549,6 +6641,30 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
changed = true;
}
+ else if (flags & FRM_NOOP)
+ {
+ /*
+ * xmax is a MultiXactId, and nothing about it changes for now.
+ * Might have to ratchet back relminmxid_out, relfrozenxid_out, or
+ * both together.
+ */
+ Assert(!freeze_xmax);
+ Assert(MultiXactIdIsValid(newxmax) && xid == newxmax);
+ Assert(TransactionIdPrecedesOrEquals(xmax_oldest_xid_out,
+ *relfrozenxid_out));
+ if (MultiXactIdPrecedes(xid, *relminmxid_out))
+ *relminmxid_out = xid;
+ *relfrozenxid_out = xmax_oldest_xid_out;
+ }
+ else
+ {
+ /*
+ * Neither keeping an Xid or a MultiXactId for xmax (freezing it).
+ * Won't have to ratchet back relminmxid_out or relfrozenxid_out.
+ */
+ Assert(freeze_xmax);
+ Assert(!TransactionIdIsValid(newxmax));
+ }
}
else if (TransactionIdIsNormal(xid))
{
@@ -6573,15 +6689,21 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
errmsg_internal("cannot freeze committed xmax %u",
xid)));
freeze_xmax = true;
+ /* No need for relfrozenxid_out handling, since we'll freeze xmax */
}
else
+ {
freeze_xmax = false;
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ }
}
else if ((tuple->t_infomask & HEAP_XMAX_INVALID) ||
!TransactionIdIsValid(HeapTupleHeaderGetRawXmax(tuple)))
{
freeze_xmax = false;
xmax_already_frozen = true;
+ /* No need for relfrozenxid_out handling for already-frozen xmax */
}
else
ereport(ERROR,
@@ -6622,6 +6744,8 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* was removed in PostgreSQL 9.0. Note that if we were to respect
* cutoff_xid here, we'd need to make surely to clear totally_frozen
* when we skipped freezing on that basis.
+ *
+ * No need for relfrozenxid_out handling, since we always freeze xvac.
*/
if (TransactionIdIsNormal(xid))
{
@@ -6699,11 +6823,14 @@ heap_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple frz;
bool do_freeze;
bool tuple_totally_frozen;
+ TransactionId relfrozenxid_out = cutoff_xid;
+ MultiXactId relminmxid_out = cutoff_multi;
do_freeze = heap_prepare_freeze_tuple(tuple,
relfrozenxid, relminmxid,
cutoff_xid, cutoff_multi,
- &frz, &tuple_totally_frozen);
+ &frz, &tuple_totally_frozen,
+ &relfrozenxid_out, &relminmxid_out);
/*
* Note that because this is not a WAL-logged operation, we don't need to
@@ -7136,79 +7263,122 @@ heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
* It doesn't matter whether the tuple is alive or dead, we are checking
* to see if a tuple needs to be removed or frozen to avoid wraparound.
*
+ * The *relfrozenxid_nofreeze_out and *relminmxid_nofreeze_out arguments are
+ * input/output arguments that are similar to heap_prepare_freeze_tuple's
+ * *relfrozenxid_out and *relminmxid_out input/output arguments. There is one
+ * big difference: we track the oldest extant XID and XMID while making a
+ * working assumption that freezing won't go ahead. heap_prepare_freeze_tuple
+ * assumes that freezing will go ahead (based on the specific instructions it
+ * provides for its caller's tuple).
+ *
+ * Note, in particular, that we even assume that freezing won't go ahead for a
+ * tuple that we indicate "needs freezing" (by returning true). Not all
+ * callers will be okay with that. Caller should make temp copies of global
+ * tracking variables, and pass us those. That way caller can back out at the
+ * last moment when it must freeze the tuple using heap_prepare_freeze_tuple.
+ *
* NB: Cannot rely on hint bits here, they might not be set after a crash or
* on a standby.
*/
bool
heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi)
+ MultiXactId cutoff_multi,
+ TransactionId *relfrozenxid_nofreeze_out,
+ MultiXactId *relminmxid_nofreeze_out)
{
+ bool needs_freeze = false;
TransactionId xid;
+ MultiXactId multi;
+ /* First deal with xmin */
xid = HeapTupleHeaderGetXmin(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ needs_freeze = true;
+ }
/*
+ * Now deal with xmax.
+ *
* The considerations for multixacts are complicated; look at
* heap_prepare_freeze_tuple for justifications. This routine had better
* be in sync with that one!
*/
+ xid = InvalidTransactionId;
+ multi = InvalidMultiXactId;
if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
- {
- MultiXactId multi;
-
multi = HeapTupleHeaderGetRawXmax(tuple);
- if (!MultiXactIdIsValid(multi))
- {
- /* no xmax set, ignore */
- ;
- }
- else if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
- return true;
- else if (MultiXactIdPrecedes(multi, cutoff_multi))
- return true;
- else
- {
- MultiXactMember *members;
- int nmembers;
- int i;
+ else
+ xid = HeapTupleHeaderGetRawXmax(tuple);
- /* need to check whether any member of the mxact is too old */
-
- nmembers = GetMultiXactIdMembers(multi, &members, false,
- HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
-
- for (i = 0; i < nmembers; i++)
- {
- if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
- {
- pfree(members);
- return true;
- }
- }
- if (nmembers > 0)
- pfree(members);
- }
+ if (TransactionIdIsNormal(xid))
+ {
+ /* xmax is a non-permanent XID */
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ needs_freeze = true;
+ }
+ else if (!MultiXactIdIsValid(multi))
+ {
+ /* xmax is a permanent XID or invalid MultiXactId/XID */
+ }
+ else if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
+ {
+ /* xmax is a pg_upgrade'd MultiXact, which can't have updater XID */
+ if (MultiXactIdPrecedes(multi, *relminmxid_nofreeze_out))
+ *relminmxid_nofreeze_out = multi;
+ /* heap_prepare_freeze_tuple always freezes pg_upgrade'd xmax */
+ needs_freeze = true;
}
else
{
- xid = HeapTupleHeaderGetRawXmax(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ /* xmax is a MultiXactId that may have an updater XID */
+ MultiXactMember *members;
+ int nmembers;
+
+ if (MultiXactIdPrecedes(multi, *relminmxid_nofreeze_out))
+ *relminmxid_nofreeze_out = multi;
+ if (MultiXactIdPrecedes(multi, cutoff_multi))
+ needs_freeze = true;
+
+ /*
+ * relfrozenxid_nofreeze_out might need to be pushed back by the
+ * oldest member XID from the mxact. Need to check its members now.
+ * (Might also affect whether we advise caller to freeze tuple.)
+ */
+ nmembers = GetMultiXactIdMembers(multi, &members, false,
+ HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
+
+ for (int i = 0; i < nmembers; i++)
+ {
+ xid = members[i].xid;
+ Assert(TransactionIdIsNormal(xid));
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ needs_freeze = true;
+ }
+ if (nmembers > 0)
+ pfree(members);
}
if (tuple->t_infomask & HEAP_MOVED)
{
xid = HeapTupleHeaderGetXvac(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_nofreeze_out))
+ *relfrozenxid_nofreeze_out = xid;
+ /* heap_prepare_freeze_tuple always freezes xvac */
+ needs_freeze = true;
+ }
}
- return false;
+ return needs_freeze;
}
/*
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 87ab7775a..723408744 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -144,7 +144,7 @@ typedef struct LVRelState
Relation *indrels;
int nindexes;
- /* Aggressive VACUUM (scan all unfrozen pages)? */
+ /* Aggressive VACUUM? (must set relfrozenxid >= FreezeLimit) */
bool aggressive;
/* Use visibility map to skip? (disabled by DISABLE_PAGE_SKIPPING) */
bool skipwithvm;
@@ -173,8 +173,9 @@ typedef struct LVRelState
/* VACUUM operation's target cutoffs for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
- /* Are FreezeLimit/MultiXactCutoff still valid? */
- bool freeze_cutoffs_valid;
+ /* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
/* Error reporting state */
char *relnamespace;
@@ -319,15 +320,15 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
skipwithvm;
bool frozenxid_updated,
minmulti_updated;
- BlockNumber orig_rel_pages;
+ BlockNumber orig_rel_pages,
+ new_rel_pages,
+ new_rel_allvisible;
char **indnames = NULL;
- BlockNumber new_rel_pages;
- BlockNumber new_rel_allvisible;
- double new_live_tuples;
ErrorContextCallback errcallback;
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
TransactionId OldestXmin;
+ MultiXactId OldestMxact;
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
@@ -351,20 +352,17 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/*
* Get OldestXmin cutoff, which is used to determine which deleted tuples
* are considered DEAD, not just RECENTLY_DEAD. Also get related cutoffs
- * used to determine which XIDs/MultiXactIds will be frozen.
- *
- * If this is an aggressive VACUUM, then we're strictly required to freeze
- * any and all XIDs from before FreezeLimit, so that we will be able to
- * safely advance relfrozenxid up to FreezeLimit below (we must be able to
- * advance relminmxid up to MultiXactCutoff, too).
+ * used to determine which XIDs/MultiXactIds will be frozen. If this is
+ * an aggressive VACUUM then lazy_scan_heap cannot leave behind unfrozen
+ * XIDs < FreezeLimit (or unfrozen MXIDs < MultiXactCutoff).
*/
aggressive = vacuum_set_xid_limits(rel,
params->freeze_min_age,
params->freeze_table_age,
params->multixact_freeze_min_age,
params->multixact_freeze_table_age,
- &OldestXmin, &FreezeLimit,
- &MultiXactCutoff);
+ &OldestXmin, &OldestMxact,
+ &FreezeLimit, &MultiXactCutoff);
skipwithvm = true;
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
@@ -511,10 +509,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->vistest = GlobalVisTestFor(rel);
/* FreezeLimit controls XID freezing (always <= OldestXmin) */
vacrel->FreezeLimit = FreezeLimit;
- /* MultiXactCutoff controls MXID freezing */
+ /* MultiXactCutoff controls MXID freezing (always <= OldestMxact) */
vacrel->MultiXactCutoff = MultiXactCutoff;
- /* Track if cutoffs became invalid (possible in !aggressive case only) */
- vacrel->freeze_cutoffs_valid = true;
+ /* Initialize state used to track oldest extant XID/XMID */
+ vacrel->NewRelfrozenXid = OldestXmin;
+ vacrel->NewRelminMxid = OldestMxact;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -548,51 +547,57 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/*
* Prepare to update rel's pg_class entry.
*
- * In principle new_live_tuples could be -1 indicating that we (still)
- * don't know the tuple count. In practice that probably can't happen,
- * since we'd surely have scanned some pages if the table is new and
- * nonempty.
- *
* For safety, clamp relallvisible to be not more than what we're setting
* relpages to.
*/
new_rel_pages = vacrel->rel_pages; /* After possible rel truncation */
- new_live_tuples = vacrel->new_live_tuples;
visibilitymap_count(rel, &new_rel_allvisible, NULL);
if (new_rel_allvisible > new_rel_pages)
new_rel_allvisible = new_rel_pages;
/*
- * Now actually update rel's pg_class entry.
- *
- * Aggressive VACUUM must reliably advance relfrozenxid (and relminmxid).
- * We are able to advance relfrozenxid in a non-aggressive VACUUM too,
- * provided we didn't skip any all-visible (not all-frozen) pages using
- * the visibility map, and assuming that we didn't fail to get a cleanup
- * lock that made it unsafe with respect to FreezeLimit (or perhaps our
- * MultiXactCutoff) established for VACUUM operation.
+ * Aggressive VACUUMs must advance relfrozenxid to a value >= FreezeLimit,
+ * and advance relminmxid to a value >= MultiXactCutoff.
*/
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
- !vacrel->freeze_cutoffs_valid)
+ Assert(!aggressive || vacrel->NewRelfrozenXid == OldestXmin ||
+ TransactionIdPrecedesOrEquals(FreezeLimit,
+ vacrel->NewRelfrozenXid));
+ Assert(!aggressive || vacrel->NewRelminMxid == OldestMxact ||
+ MultiXactIdPrecedesOrEquals(MultiXactCutoff,
+ vacrel->NewRelminMxid));
+
+ /*
+ * Non-aggressive VACUUMs might advance relfrozenxid to an XID that is
+ * either older or newer than FreezeLimit (same applies to relminmxid and
+ * MultiXactCutoff). But the state that tracks the oldest remaining XID
+ * and MXID cannot be trusted when any all-visible pages were skipped.
+ */
+ Assert(vacrel->NewRelfrozenXid == OldestXmin ||
+ TransactionIdPrecedesOrEquals(vacrel->relfrozenxid,
+ vacrel->NewRelfrozenXid));
+ Assert(vacrel->NewRelminMxid == OldestMxact ||
+ MultiXactIdPrecedesOrEquals(vacrel->relminmxid,
+ vacrel->NewRelminMxid));
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
{
- /* Cannot advance relfrozenxid/relminmxid */
+ /* Keep existing relfrozenxid and relminmxid (can't trust trackers) */
Assert(!aggressive);
- frozenxid_updated = minmulti_updated = false;
- vac_update_relstats(rel, new_rel_pages, new_live_tuples,
- new_rel_allvisible, vacrel->nindexes > 0,
- InvalidTransactionId, InvalidMultiXactId,
- NULL, NULL, false);
- }
- else
- {
- Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
- orig_rel_pages);
- vac_update_relstats(rel, new_rel_pages, new_live_tuples,
- new_rel_allvisible, vacrel->nindexes > 0,
- FreezeLimit, MultiXactCutoff,
- &frozenxid_updated, &minmulti_updated, false);
+ vacrel->NewRelfrozenXid = InvalidTransactionId;
+ vacrel->NewRelminMxid = InvalidMultiXactId;
}
+ /*
+ * Now actually update rel's pg_class entry
+ *
+ * In principle new_live_tuples could be -1 indicating that we (still)
+ * don't know the tuple count. In practice that can't happen, since we
+ * scan every page that isn't skipped using the visibility map.
+ */
+ vac_update_relstats(rel, new_rel_pages, vacrel->new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ vacrel->NewRelfrozenXid, vacrel->NewRelminMxid,
+ &frozenxid_updated, &minmulti_updated, false);
+
/*
* Report results to the stats collector, too.
*
@@ -605,7 +610,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
*/
pgstat_report_vacuum(RelationGetRelid(rel),
rel->rd_rel->relisshared,
- Max(new_live_tuples, 0),
+ Max(vacrel->new_live_tuples, 0),
vacrel->recently_dead_tuples +
vacrel->missed_dead_tuples);
pgstat_progress_end_command();
@@ -694,17 +699,19 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
OldestXmin, diff);
if (frozenxid_updated)
{
- diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
+ diff = (int32) (vacrel->NewRelfrozenXid - vacrel->relfrozenxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relfrozenxid: %u, which is %d xids ahead of previous value\n"),
- FreezeLimit, diff);
+ vacrel->NewRelfrozenXid, diff);
}
if (minmulti_updated)
{
- diff = (int32) (MultiXactCutoff - vacrel->relminmxid);
+ diff = (int32) (vacrel->NewRelminMxid - vacrel->relminmxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relminmxid: %u, which is %d mxids ahead of previous value\n"),
- MultiXactCutoff, diff);
+ vacrel->NewRelminMxid, diff);
}
if (orig_rel_pages > 0)
{
@@ -1584,6 +1591,8 @@ lazy_scan_prune(LVRelState *vacrel,
recently_dead_tuples;
int nnewlpdead;
int nfrozen;
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
@@ -1593,7 +1602,9 @@ lazy_scan_prune(LVRelState *vacrel,
retry:
- /* Initialize (or reset) page-level counters */
+ /* Initialize (or reset) page-level state */
+ NewRelfrozenXid = vacrel->NewRelfrozenXid;
+ NewRelminMxid = vacrel->NewRelminMxid;
tuples_deleted = 0;
lpdead_items = 0;
live_tuples = 0;
@@ -1801,7 +1812,8 @@ retry:
vacrel->FreezeLimit,
vacrel->MultiXactCutoff,
&frozen[nfrozen],
- &tuple_totally_frozen))
+ &tuple_totally_frozen,
+ &NewRelfrozenXid, &NewRelminMxid))
{
/* Will execute freeze below */
frozen[nfrozen++].offset = offnum;
@@ -1815,13 +1827,16 @@ retry:
prunestate->all_frozen = false;
}
+ vacrel->offnum = InvalidOffsetNumber;
+
/*
* We have now divided every item on the page into either an LP_DEAD item
* that will need to be vacuumed in indexes later, or a LP_NORMAL tuple
* that remains and needs to be considered for freezing now (LP_UNUSED and
* LP_REDIRECT items also remain, but are of no further interest to us).
*/
- vacrel->offnum = InvalidOffsetNumber;
+ vacrel->NewRelfrozenXid = NewRelfrozenXid;
+ vacrel->NewRelminMxid = NewRelminMxid;
/*
* Consider the need to freeze any items with tuple storage from the page
@@ -1972,6 +1987,8 @@ lazy_scan_noprune(LVRelState *vacrel,
missed_dead_tuples;
HeapTupleHeader tupleheader;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
+ TransactionId NoFreezeNewRelfrozenXid = vacrel->NewRelfrozenXid;
+ MultiXactId NoFreezeNewRelminMxid = vacrel->NewRelminMxid;
Assert(BufferGetBlockNumber(buf) == blkno);
@@ -2017,20 +2034,39 @@ lazy_scan_noprune(LVRelState *vacrel,
tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
if (heap_tuple_needs_freeze(tupleheader,
vacrel->FreezeLimit,
- vacrel->MultiXactCutoff))
+ vacrel->MultiXactCutoff,
+ &NoFreezeNewRelfrozenXid,
+ &NoFreezeNewRelminMxid))
{
+ /* Tuple with XID < FreezeLimit (or MXID < MultiXactCutoff) */
+
if (vacrel->aggressive)
{
- /* Going to have to get cleanup lock for lazy_scan_prune */
+ /*
+ * Aggressive VACUUMs must always be able to advance rel's
+ * relfrozenxid to a value >= FreezeLimit (and to advance
+ * rel's relminmxid to a value >= MultiXactCutoff). The
+ * ongoing aggressive VACUUM cannot satisfy these requirements
+ * without freezing an XID (or XMID) from this tuple.
+ *
+ * The only safe option is to have caller perform processing
+ * of this page using lazy_scan_prune. Caller might have to
+ * wait a while for a cleanup lock, but it can't be helped.
+ */
vacrel->offnum = InvalidOffsetNumber;
return false;
}
-
- /*
- * Current non-aggressive VACUUM operation definitely won't be
- * able to advance relfrozenxid or relminmxid
- */
- vacrel->freeze_cutoffs_valid = false;
+ else
+ {
+ /*
+ * Standard VACUUMs are not obligated to advance relfrozenxid
+ * or relminmxid by any amount, so we can be much laxer here.
+ *
+ * Currently we always just accept an older final relfrozenxid
+ * and/or relminmxid value. We never make caller wait or work
+ * a little harder, even when it likely makes sense to do so.
+ */
+ }
}
ItemPointerSet(&(tuple.t_self), blkno, offnum);
@@ -2080,9 +2116,14 @@ lazy_scan_noprune(LVRelState *vacrel,
vacrel->offnum = InvalidOffsetNumber;
/*
- * Now save details of the LP_DEAD items from the page in vacrel (though
- * only when VACUUM uses two-pass strategy)
+ * By here we know for sure that caller can tolerate reduced processing
+ * for this particular page. Save all of the details in vacrel now.
+ * (lazy_scan_prune expects a clean slate, so we have to do this last.)
*/
+ vacrel->NewRelfrozenXid = NoFreezeNewRelfrozenXid;
+ vacrel->NewRelminMxid = NoFreezeNewRelminMxid;
+
+ /* Save details of the LP_DEAD items from the page */
if (vacrel->nindexes == 0)
{
/* Using one-pass strategy (since table has no indexes) */
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c
index 02a7e94bf..a7e988298 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/cluster.c
@@ -767,6 +767,7 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
TupleDesc oldTupDesc PG_USED_FOR_ASSERTS_ONLY;
TupleDesc newTupDesc PG_USED_FOR_ASSERTS_ONLY;
TransactionId OldestXmin;
+ MultiXactId oldestMxact;
TransactionId FreezeXid;
MultiXactId MultiXactCutoff;
bool use_sort;
@@ -856,8 +857,8 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
* Since we're going to rewrite the whole table anyway, there's no reason
* not to be aggressive about this.
*/
- vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0,
- &OldestXmin, &FreezeXid, &MultiXactCutoff);
+ vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0, &OldestXmin, &oldestMxact,
+ &FreezeXid, &MultiXactCutoff);
/*
* FreezeXid will become the table's new relfrozenxid, and that mustn't go
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 50a4a612e..0ae3b4506 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -945,14 +945,22 @@ get_all_vacuum_rels(int options)
* The output parameters are:
* - oldestXmin is the Xid below which tuples deleted by any xact (that
* committed) should be considered DEAD, not just RECENTLY_DEAD.
- * - freezeLimit is the Xid below which all Xids are replaced by
- * FrozenTransactionId during vacuum.
- * - multiXactCutoff is the value below which all MultiXactIds are removed
- * from Xmax.
+ * - oldestMxact is the Mxid below which MultiXacts are definitely not
+ * seen as visible by any running transaction.
+ * - freezeLimit is the Xid below which all Xids are definitely replaced by
+ * FrozenTransactionId during aggressive vacuums.
+ * - multiXactCutoff is the value below which all MultiXactIds are definitely
+ * removed from Xmax during aggressive vacuums.
*
* Return value indicates if vacuumlazy.c caller should make its VACUUM
* operation aggressive. An aggressive VACUUM must advance relfrozenxid up to
- * FreezeLimit, and relminmxid up to multiXactCutoff.
+ * FreezeLimit (at a minimum), and relminmxid up to multiXactCutoff (at a
+ * minimum).
+ *
+ * oldestXmin and oldestMxact are the most recent values that can ever be
+ * passed to vac_update_relstats() as frozenxid and minmulti arguments by our
+ * vacuumlazy.c caller later on. These values should be passed when it turns
+ * out that VACUUM will leave no unfrozen XIDs/XMIDs behind in the table.
*/
bool
vacuum_set_xid_limits(Relation rel,
@@ -961,6 +969,7 @@ vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff)
{
@@ -969,7 +978,6 @@ vacuum_set_xid_limits(Relation rel,
int effective_multixact_freeze_max_age;
TransactionId limit;
TransactionId safeLimit;
- MultiXactId oldestMxact;
MultiXactId mxactLimit;
MultiXactId safeMxactLimit;
int freezetable;
@@ -1065,9 +1073,11 @@ vacuum_set_xid_limits(Relation rel,
effective_multixact_freeze_max_age / 2);
Assert(mxid_freezemin >= 0);
+ /* Remember for caller */
+ *oldestMxact = GetOldestMultiXactId();
+
/* compute the cutoff multi, being careful to generate a valid value */
- oldestMxact = GetOldestMultiXactId();
- mxactLimit = oldestMxact - mxid_freezemin;
+ mxactLimit = *oldestMxact - mxid_freezemin;
if (mxactLimit < FirstMultiXactId)
mxactLimit = FirstMultiXactId;
@@ -1082,8 +1092,8 @@ vacuum_set_xid_limits(Relation rel,
(errmsg("oldest multixact is far in the past"),
errhint("Close open transactions with multixacts soon to avoid wraparound problems.")));
/* Use the safe limit, unless an older mxact is still running */
- if (MultiXactIdPrecedes(oldestMxact, safeMxactLimit))
- mxactLimit = oldestMxact;
+ if (MultiXactIdPrecedes(*oldestMxact, safeMxactLimit))
+ mxactLimit = *oldestMxact;
else
mxactLimit = safeMxactLimit;
}
@@ -1390,14 +1400,10 @@ vac_update_relstats(Relation relation,
* Update relfrozenxid, unless caller passed InvalidTransactionId
* indicating it has no new data.
*
- * Ordinarily, we don't let relfrozenxid go backwards: if things are
- * working correctly, the only way the new frozenxid could be older would
- * be if a previous VACUUM was done with a tighter freeze_min_age, in
- * which case we don't want to forget the work it already did. However,
- * if the stored relfrozenxid is "in the future", then it must be corrupt
- * and it seems best to overwrite it with the cutoff we used this time.
- * This should match vac_update_datfrozenxid() concerning what we consider
- * to be "in the future".
+ * Ordinarily, we don't let relfrozenxid go backwards. However, if the
+ * stored relfrozenxid is "in the future", then it must be corrupt, so
+ * just overwrite it. This should match vac_update_datfrozenxid()
+ * concerning what we consider to be "in the future".
*/
if (frozenxid_updated)
*frozenxid_updated = false;
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 36f975b1e..6a02d0fa8 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -563,9 +563,11 @@
statistics in the system tables <structname>pg_class</structname> and
<structname>pg_database</structname>. In particular,
the <structfield>relfrozenxid</structfield> column of a table's
- <structname>pg_class</structname> row contains the freeze cutoff XID that was used
- by the last aggressive <command>VACUUM</command> for that table. All rows
- inserted by transactions with XIDs older than this cutoff XID are
+ <structname>pg_class</structname> row contains the oldest
+ remaining XID at the end of the most recent <command>VACUUM</command>
+ that successfully advanced <structfield>relfrozenxid</structfield>
+ (typically the most recent aggressive VACUUM). All rows inserted
+ by transactions with XIDs older than this cutoff XID are
guaranteed to have been frozen. Similarly,
the <structfield>datfrozenxid</structfield> column of a database's
<structname>pg_database</structname> row is a lower bound on the unfrozen XIDs
@@ -588,6 +590,17 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
cutoff XID to the current transaction's XID.
</para>
+ <tip>
+ <para>
+ <literal>VACUUM VERBOSE</literal> outputs information about
+ <structfield>relfrozenxid</structfield> and/or
+ <structfield>relminmxid</structfield> when either field was
+ advanced. The same details appear in the server log when <xref
+ linkend="guc-log-autovacuum-min-duration"/> reports on vacuuming
+ by autovacuum.
+ </para>
+ </tip>
+
<para>
<command>VACUUM</command> normally only scans pages that have been modified
since the last vacuum, but <structfield>relfrozenxid</structfield> can only be
@@ -602,7 +615,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
set <literal>age(relfrozenxid)</literal> to a value just a little more than the
<varname>vacuum_freeze_min_age</varname> setting
that was used (more by the number of transactions started since the
- <command>VACUUM</command> started). If no <structfield>relfrozenxid</structfield>-advancing
+ <command>VACUUM</command> started). <command>VACUUM</command>
+ will set <structfield>relfrozenxid</structfield> to the oldest XID
+ that remains in the table, so it's possible that the final value
+ will be much more recent than strictly required.
+ If no <structfield>relfrozenxid</structfield>-advancing
<command>VACUUM</command> is issued on the table until
<varname>autovacuum_freeze_max_age</varname> is reached, an autovacuum will soon
be forced for the table.
@@ -689,8 +706,9 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
</para>
<para>
- Aggressive <command>VACUUM</command> scans, regardless of
- what causes them, enable advancing the value for that table.
+ Aggressive <command>VACUUM</command> scans, regardless of what
+ causes them, are <emphasis>guaranteed</emphasis> to be able to
+ advance the table's <structfield>relminmxid</structfield>.
Eventually, as all tables in all databases are scanned and their
oldest multixact values are advanced, on-disk storage for older
multixacts can be removed.
diff --git a/src/test/isolation/expected/vacuum-no-cleanup-lock.out b/src/test/isolation/expected/vacuum-no-cleanup-lock.out
new file mode 100644
index 000000000..f7bc93e8f
--- /dev/null
+++ b/src/test/isolation/expected/vacuum-no-cleanup-lock.out
@@ -0,0 +1,189 @@
+Parsed test spec with 4 sessions
+
+starting permutation: vacuumer_pg_class_stats dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+
+starting permutation: vacuumer_pg_class_stats dml_insert pinholder_cursor vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: vacuumer_pg_class_stats pinholder_cursor dml_insert dml_delete dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step dml_delete:
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: vacuumer_pg_class_stats dml_insert dml_delete pinholder_cursor dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step dml_delete:
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: dml_begin dml_other_begin dml_key_share dml_other_key_share vacuumer_nonaggressive_vacuum pinholder_cursor dml_other_update dml_commit dml_other_commit vacuumer_nonaggressive_vacuum pinholder_commit vacuumer_nonaggressive_vacuum
+step dml_begin: BEGIN;
+step dml_other_begin: BEGIN;
+step dml_key_share: SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE;
+id
+--
+ 3
+(1 row)
+
+step dml_other_key_share: SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE;
+id
+--
+ 3
+(1 row)
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_other_update: UPDATE smalltbl SET t = 'u' WHERE id = 3;
+step dml_commit: COMMIT;
+step dml_other_commit: COMMIT;
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step pinholder_commit:
+ COMMIT;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
diff --git a/src/test/isolation/expected/vacuum-reltuples.out b/src/test/isolation/expected/vacuum-reltuples.out
deleted file mode 100644
index ce55376e7..000000000
--- a/src/test/isolation/expected/vacuum-reltuples.out
+++ /dev/null
@@ -1,67 +0,0 @@
-Parsed test spec with 2 sessions
-
-starting permutation: modify vac stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step vac:
- vacuum smalltbl;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
-
-starting permutation: modify open fetch1 vac close stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step open:
- begin;
- declare c1 cursor for select 1 as dummy from smalltbl;
-
-step fetch1:
- fetch next from c1;
-
-dummy
------
- 1
-(1 row)
-
-step vac:
- vacuum smalltbl;
-
-step close:
- commit;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
-
-starting permutation: modify vac stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step vac:
- vacuum smalltbl;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
diff --git a/src/test/isolation/isolation_schedule b/src/test/isolation/isolation_schedule
index 8e8709815..35e0d1ee4 100644
--- a/src/test/isolation/isolation_schedule
+++ b/src/test/isolation/isolation_schedule
@@ -80,7 +80,7 @@ test: alter-table-4
test: create-trigger
test: sequence-ddl
test: async-notify
-test: vacuum-reltuples
+test: vacuum-no-cleanup-lock
test: timeouts
test: vacuum-concurrent-drop
test: vacuum-conflict
diff --git a/src/test/isolation/specs/vacuum-no-cleanup-lock.spec b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec
new file mode 100644
index 000000000..a88be66de
--- /dev/null
+++ b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec
@@ -0,0 +1,150 @@
+# Test for vacuum's reduced processing of heap pages (used for any heap page
+# where a cleanup lock isn't immediately available)
+#
+# Debugging tip: Change VACUUM to VACUUM VERBOSE to get feedback on what's
+# really going on
+
+# Use name type here to avoid TOAST table:
+setup
+{
+ CREATE TABLE smalltbl AS SELECT i AS id, 't'::name AS t FROM generate_series(1,20) i;
+ ALTER TABLE smalltbl SET (autovacuum_enabled = off);
+ ALTER TABLE smalltbl ADD PRIMARY KEY (id);
+}
+setup
+{
+ VACUUM ANALYZE smalltbl;
+}
+
+teardown
+{
+ DROP TABLE smalltbl;
+}
+
+# This session holds a pin on smalltbl's only heap page:
+session pinholder
+step pinholder_cursor
+{
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+}
+step pinholder_commit
+{
+ COMMIT;
+}
+
+# This session inserts and deletes tuples, potentially affecting reltuples:
+session dml
+step dml_insert
+{
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+}
+step dml_delete
+{
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+}
+step dml_begin { BEGIN; }
+step dml_key_share { SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; }
+step dml_commit { COMMIT; }
+
+# Needed for Multixact test:
+session dml_other
+step dml_other_begin { BEGIN; }
+step dml_other_key_share { SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; }
+step dml_other_update { UPDATE smalltbl SET t = 'u' WHERE id = 3; }
+step dml_other_commit { COMMIT; }
+
+# This session runs non-aggressive VACUUM, but with maximally aggressive
+# cutoffs for tuple freezing (e.g., FreezeLimit == OldestXmin):
+session vacuumer
+setup
+{
+ SET vacuum_freeze_min_age = 0;
+ SET vacuum_multixact_freeze_min_age = 0;
+}
+step vacuumer_nonaggressive_vacuum
+{
+ VACUUM smalltbl;
+}
+step vacuumer_pg_class_stats
+{
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+}
+
+# Test VACUUM's reltuples counting mechanism.
+#
+# Final pg_class.reltuples should never be affected by VACUUM's inability to
+# get a cleanup lock on any page, except to the extent that any cleanup lock
+# contention changes the number of tuples that remain ("missed dead" tuples
+# are counted in reltuples, much like "recently dead" tuples).
+
+# Easy case:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ vacuumer_pg_class_stats # End with 21 tuples
+
+# Harder case -- count 21 tuples at the end (like last time), but with cleanup
+# lock contention this time:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ pinholder_cursor
+ vacuumer_nonaggressive_vacuum
+ vacuumer_pg_class_stats # End with 21 tuples
+ pinholder_commit # order doesn't matter
+
+# Same as "harder case", but vary the order, and delete an inserted row:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ pinholder_cursor
+ dml_insert
+ dml_delete
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ # reltuples is 21 here again -- "recently dead" tuple won't be included in
+ # count here:
+ vacuumer_pg_class_stats
+ pinholder_commit # order doesn't matter
+
+# Same as "harder case", but initial insert and delete before cursor:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ dml_delete
+ pinholder_cursor
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ # reltuples is 21 here again -- "missed dead" tuple ("recently dead" when
+ # concurrent activity held back VACUUM's OldestXmin) won't be included in
+ # count here:
+ vacuumer_pg_class_stats
+ pinholder_commit # order doesn't matter
+
+# Test VACUUM's mechanism for skipping MultiXact freezing.
+#
+# This provides test coverage for code paths that are only hit when we need to
+# freeze, but inability to acquire a cleanup lock on a heap page makes
+# freezing some XIDs/XMIDs < FreezeLimit/MultiXactCutoff impossible (without
+# waiting for a cleanup lock, which non-aggressive VACUUM is unwilling to do).
+permutation
+ dml_begin
+ dml_other_begin
+ dml_key_share
+ dml_other_key_share
+ # Will get cleanup lock, can't advance relminmxid yet:
+ # (though will usually advance relfrozenxid by ~2 XIDs)
+ vacuumer_nonaggressive_vacuum
+ pinholder_cursor
+ dml_other_update
+ dml_commit
+ dml_other_commit
+ # Can't cleanup lock, so still can't advance relminmxid here:
+ # (relfrozenxid held back by XIDs in MultiXact too)
+ vacuumer_nonaggressive_vacuum
+ pinholder_commit
+ # Pin was dropped, so will advance relminmxid, at long last:
+ # (ditto for relfrozenxid advancement)
+ vacuumer_nonaggressive_vacuum
diff --git a/src/test/isolation/specs/vacuum-reltuples.spec b/src/test/isolation/specs/vacuum-reltuples.spec
deleted file mode 100644
index a2a461f2f..000000000
--- a/src/test/isolation/specs/vacuum-reltuples.spec
+++ /dev/null
@@ -1,49 +0,0 @@
-# Test for vacuum's handling of reltuples when pages are skipped due
-# to page pins. We absolutely need to avoid setting reltuples=0 in
-# such cases, since that interferes badly with planning.
-#
-# Expected result for all three permutation is 21 tuples, including
-# the second permutation. VACUUM is able to count the concurrently
-# inserted tuple in its final reltuples, even when a cleanup lock
-# cannot be acquired on the affected heap page.
-
-setup {
- create table smalltbl
- as select i as id from generate_series(1,20) i;
- alter table smalltbl set (autovacuum_enabled = off);
-}
-setup {
- vacuum analyze smalltbl;
-}
-
-teardown {
- drop table smalltbl;
-}
-
-session worker
-step open {
- begin;
- declare c1 cursor for select 1 as dummy from smalltbl;
-}
-step fetch1 {
- fetch next from c1;
-}
-step close {
- commit;
-}
-step stats {
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-}
-
-session vacuumer
-step vac {
- vacuum smalltbl;
-}
-step modify {
- insert into smalltbl select max(id)+1 from smalltbl;
-}
-
-permutation modify vac stats
-permutation modify open fetch1 vac close stats
-permutation modify vac stats
--
2.32.0
[application/octet-stream] v12-0003-vacuumlazy.c-Move-resource-allocation-to-heap_va.patch (5.0K, ../../CAH2-Wzk3fNBa_S3Ngi+16GQiyJ=AmUu3oUY99syMDTMRxitfyQ@mail.gmail.com/3-v12-0003-vacuumlazy.c-Move-resource-allocation-to-heap_va.patch)
download | inline diff:
From 7aabff81998ad3f500aa8c6da354ea2e81cee10c Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 25 Mar 2022 12:51:05 -0700
Subject: [PATCH v12 3/3] vacuumlazy.c: Move resource allocation to
heap_vacuum_rel().
Finish off work started by commit 73f6ec3d: move remaining resource
allocation and deallocation code from lazy_scan_heap() to its caller,
heap_vacuum_rel().
---
src/backend/access/heap/vacuumlazy.c | 68 ++++++++++++----------------
1 file changed, 28 insertions(+), 40 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index c647d60bc..7e641036e 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -246,7 +246,7 @@ typedef struct LVSavedErrInfo
/* non-export function prototypes */
-static void lazy_scan_heap(LVRelState *vacrel, int nworkers);
+static void lazy_scan_heap(LVRelState *vacrel);
static BlockNumber lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer,
BlockNumber next_block,
bool *next_unskippable_allvis,
@@ -519,11 +519,28 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->NewRelminMxid = OldestMxact;
vacrel->skippedallvis = false;
+ /*
+ * Allocate dead_items array memory using dead_items_alloc. This handles
+ * parallel VACUUM initialization as part of allocating shared memory
+ * space used for dead_items. (But do a failsafe precheck first, to
+ * ensure that parallel VACUUM won't be attempted at all when relfrozenxid
+ * is already dangerously old.)
+ */
+ lazy_check_wraparound_failsafe(vacrel);
+ dead_items_alloc(vacrel, params->nworkers);
+
/*
* Call lazy_scan_heap to perform all required heap pruning, index
* vacuuming, and heap vacuuming (plus related processing)
*/
- lazy_scan_heap(vacrel, params->nworkers);
+ lazy_scan_heap(vacrel);
+
+ /*
+ * Free resources managed by dead_items_alloc. This ends parallel mode in
+ * passing when necessary.
+ */
+ dead_items_cleanup(vacrel);
+ Assert(!IsInParallelMode());
/*
* Update pg_class entries for each of rel's indexes where appropriate.
@@ -833,14 +850,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* supply.
*/
static void
-lazy_scan_heap(LVRelState *vacrel, int nworkers)
+lazy_scan_heap(LVRelState *vacrel)
{
- VacDeadItems *dead_items;
BlockNumber rel_pages = vacrel->rel_pages,
blkno,
next_unskippable_block,
- next_failsafe_block,
- next_fsm_block_to_vacuum;
+ next_failsafe_block = 0,
+ next_fsm_block_to_vacuum = 0;
+ VacDeadItems *dead_items = vacrel->dead_items;
Buffer vmbuffer = InvalidBuffer;
bool next_unskippable_allvis,
skipping_current_range;
@@ -851,23 +868,6 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
};
int64 initprog_val[3];
- /*
- * Do failsafe precheck before calling dead_items_alloc. This ensures
- * that parallel VACUUM won't be attempted when relfrozenxid is already
- * dangerously old.
- */
- lazy_check_wraparound_failsafe(vacrel);
- next_failsafe_block = 0;
-
- /*
- * Allocate the space for dead_items. Note that this handles parallel
- * VACUUM initialization as part of allocating shared memory space used
- * for dead_items.
- */
- dead_items_alloc(vacrel, nworkers);
- dead_items = vacrel->dead_items;
- next_fsm_block_to_vacuum = 0;
-
/* Report that we're scanning the heap, advertising total # of blocks */
initprog_val[0] = PROGRESS_VACUUM_PHASE_SCAN_HEAP;
initprog_val[1] = rel_pages;
@@ -1244,12 +1244,11 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
}
}
+ vacrel->blkno = InvalidBlockNumber;
+
/* report that everything is now scanned */
pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
- /* Clear the block number information */
- vacrel->blkno = InvalidBlockNumber;
-
/* now we can compute the new value for pg_class.reltuples */
vacrel->new_live_tuples = vac_estimate_reltuples(vacrel->rel, rel_pages,
vacrel->scanned_pages,
@@ -1264,15 +1263,11 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
vacrel->missed_dead_tuples;
/*
- * Release any remaining pin on visibility map page.
+ * Do index vacuuming (call each index's ambulkdelete routine), then do
+ * related heap vacuuming
*/
if (BufferIsValid(vmbuffer))
- {
ReleaseBuffer(vmbuffer);
- vmbuffer = InvalidBuffer;
- }
-
- /* Perform a final round of index and heap vacuuming */
if (dead_items->num_items > 0)
lazy_vacuum(vacrel);
@@ -1286,16 +1281,9 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/* report all blocks vacuumed */
pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_VACUUMED, blkno);
- /* Do post-vacuum cleanup */
+ /* Do final index cleanup (call each index's amvacuumcleanup routine) */
if (vacrel->nindexes > 0 && vacrel->do_index_cleanup)
lazy_cleanup_all_indexes(vacrel);
-
- /*
- * Free resources managed by dead_items_alloc. This ends parallel mode in
- * passing when necessary.
- */
- dead_items_cleanup(vacrel);
- Assert(!IsInParallelMode());
}
/*
--
2.32.0
[application/octet-stream] v12-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch (19.2K, ../../CAH2-Wzk3fNBa_S3Ngi+16GQiyJ=AmUu3oUY99syMDTMRxitfyQ@mail.gmail.com/4-v12-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch)
download | inline diff:
From d359145664f8efe54376ff3bb0b26a07ebbba965 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v12 2/3] Generalize how VACUUM skips all-frozen pages.
Non-aggressive VACUUMs were at a gratuitous disadvantage (relative to
aggressive VACUUMs) around advancing relfrozenxid before now. The
underlying issue was that lazy_scan_heap conditioned its skipping
behavior on whether or not the current VACUUM was aggressive. VACUUM
could fail to increment its frozenskipped_pages counter as a result, and
so could miss out on advancing relfrozenxid (in the non-aggressive case)
for no good reason.
The issue only comes up when concurrent activity might unset a page's
visibility map bit at exactly the wrong time. The non-aggressive case
rechecked the visibility map at the point of skipping each page before
now. This created a window for some other session to concurrently unset
the same heap page's bit in the visibility map. If the bit was unset at
the wrong time, it would cause VACUUM to conservatively conclude that
the page was _never_ all-frozen on recheck. frozenskipped_pages would
not be incremented for the page as a result. lazy_scan_heap had already
committed to skipping the page/range at that point, though -- which made
it unsafe to advance relfrozenxid/relminmxid later on.
Consistently avoid the issue by generalizing how we skip frozen pages
during aggressive VACUUMs: take the same approach when skipping any
skippable page range during aggressive and non-aggressive VACUUMs alike.
The new approach makes ranges (not individual pages) the fundamental
unit of skipping using the visibility map. frozenskipped_pages is
replaced with a boolean flag that represents whether some skippable
range with one or more all-visible pages was actually skipped (making
relfrozenxid unsafe to update).
It is safe for VACUUM to treat a page as all-frozen provided it at least
had its all-frozen bit set after the OldestXmin cutoff was established.
VACUUM is only required to scan pages that might have XIDs < OldestXmin
that are not yet frozen to be able to safely advance relfrozenxid.
Tuples concurrently inserted on skipped pages are equivalent to tuples
concurrently inserted on a block >= rel_pages from the same table.
It's possible that the issue this commit fixes hardly ever came up in
practice. But we only had to be unlucky once to lose out on advancing
relfrozenxid -- a single affected heap page was enough to throw VACUUM
off. That seems like something to avoid on general principle. This is
similar to an issue fixed by commit 44fa8488, which taught vacuumlazy.c
to not give up on non-aggressive relfrozenxid advancement just because a
cleanup lock wasn't immediately available on some heap page.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Robert Haas <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wzn6bGJGfOy3zSTJicKLw99PHJeSOQBOViKjSCinaxUKDQ@mail.gmail.com
Discussion: https://postgr.es/m/CA+TgmobhuzSR442_cfpgxidmiRdL-GdaFSc8SD=GJcpLTx_BAw@mail.gmail.com
---
src/backend/access/heap/vacuumlazy.c | 309 +++++++++++++--------------
1 file changed, 146 insertions(+), 163 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 723408744..c647d60bc 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -176,6 +176,7 @@ typedef struct LVRelState
/* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
TransactionId NewRelfrozenXid;
MultiXactId NewRelminMxid;
+ bool skippedallvis;
/* Error reporting state */
char *relnamespace;
@@ -196,7 +197,6 @@ typedef struct LVRelState
VacDeadItems *dead_items; /* TIDs whose index tuples we'll delete */
BlockNumber rel_pages; /* total number of pages */
BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
- BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber removed_pages; /* # pages removed by relation truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber missed_dead_pages; /* # pages with missed dead tuples */
@@ -247,6 +247,10 @@ typedef struct LVSavedErrInfo
/* non-export function prototypes */
static void lazy_scan_heap(LVRelState *vacrel, int nworkers);
+static BlockNumber lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer,
+ BlockNumber next_block,
+ bool *next_unskippable_allvis,
+ bool *skipping_current_range);
static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf,
BlockNumber blkno, Page page,
bool sharelock, Buffer vmbuffer);
@@ -467,7 +471,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize page counters explicitly (be tidy) */
vacrel->scanned_pages = 0;
- vacrel->frozenskipped_pages = 0;
vacrel->removed_pages = 0;
vacrel->lpdead_item_pages = 0;
vacrel->missed_dead_pages = 0;
@@ -514,6 +517,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize state used to track oldest extant XID/XMID */
vacrel->NewRelfrozenXid = OldestXmin;
vacrel->NewRelminMxid = OldestMxact;
+ vacrel->skippedallvis = false;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -578,7 +582,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
Assert(vacrel->NewRelminMxid == OldestMxact ||
MultiXactIdPrecedesOrEquals(vacrel->relminmxid,
vacrel->NewRelminMxid));
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
+ if (vacrel->skippedallvis)
{
/* Keep existing relfrozenxid and relminmxid (can't trust trackers) */
Assert(!aggressive);
@@ -838,7 +842,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
next_failsafe_block,
next_fsm_block_to_vacuum;
Buffer vmbuffer = InvalidBuffer;
- bool skipping_blocks;
+ bool next_unskippable_allvis,
+ skipping_current_range;
const int initprog_index[] = {
PROGRESS_VACUUM_PHASE,
PROGRESS_VACUUM_TOTAL_HEAP_BLKS,
@@ -869,179 +874,52 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
initprog_val[2] = dead_items->max_items;
pgstat_progress_update_multi_param(3, initprog_index, initprog_val);
- /*
- * Set things up for skipping blocks using visibility map.
- *
- * Except when vacrel->aggressive is set, we want to skip pages that are
- * all-visible according to the visibility map, but only when we can skip
- * at least SKIP_PAGES_THRESHOLD consecutive pages. Since we're reading
- * sequentially, the OS should be doing readahead for us, so there's no
- * gain in skipping a page now and then; that's likely to disable
- * readahead and so be counterproductive. Also, skipping even a single
- * page means that we can't update relfrozenxid, so we only want to do it
- * if we can skip a goodly number of pages.
- *
- * When vacrel->aggressive is set, we can't skip pages just because they
- * are all-visible, but we can still skip pages that are all-frozen, since
- * such pages do not need freezing and do not affect the value that we can
- * safely set for relfrozenxid or relminmxid.
- *
- * Before entering the main loop, establish the invariant that
- * next_unskippable_block is the next block number >= blkno that we can't
- * skip based on the visibility map, either all-visible for a regular scan
- * or all-frozen for an aggressive scan. We set it to rel_pages when
- * there's no such block. We also set up the skipping_blocks flag
- * correctly at this stage.
- *
- * Note: The value returned by visibilitymap_get_status could be slightly
- * out-of-date, since we make this test before reading the corresponding
- * heap page or locking the buffer. This is OK. If we mistakenly think
- * that the page is all-visible or all-frozen when in fact the flag's just
- * been cleared, we might fail to vacuum the page. It's easy to see that
- * skipping a page when aggressive is not set is not a very big deal; we
- * might leave some dead tuples lying around, but the next vacuum will
- * find them. But even when aggressive *is* set, it's still OK if we miss
- * a page whose all-frozen marking has just been cleared. Any new XIDs
- * just added to that page are necessarily >= vacrel->OldestXmin, and so
- * they'll have no effect on the value to which we can safely set
- * relfrozenxid. A similar argument applies for MXIDs and relminmxid.
- */
- next_unskippable_block = 0;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmstatus;
-
- vmstatus = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmstatus & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
-
- if (next_unskippable_block >= SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
-
+ /* Set up an initial range of skippable blocks using the visibility map */
+ next_unskippable_block = lazy_scan_skip(vacrel, &vmbuffer, 0,
+ &next_unskippable_allvis,
+ &skipping_current_range);
for (blkno = 0; blkno < rel_pages; blkno++)
{
Buffer buf;
Page page;
- bool all_visible_according_to_vm = false;
+ bool all_visible_according_to_vm;
LVPagePruneState prunestate;
- pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
-
- update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
- blkno, InvalidOffsetNumber);
-
if (blkno == next_unskippable_block)
{
- /* Time to advance next_unskippable_block */
- next_unskippable_block++;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmskipflags;
-
- vmskipflags = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
-
/*
- * We know we can't skip the current block. But set up
- * skipping_blocks to do the right thing at the following blocks.
+ * Can't skip this page safely. Must scan the page. But
+ * determine the next skippable range after the page first.
*/
- if (next_unskippable_block - blkno > SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
+ all_visible_according_to_vm = next_unskippable_allvis;
+ next_unskippable_block = lazy_scan_skip(vacrel, &vmbuffer,
+ blkno + 1,
+ &next_unskippable_allvis,
+ &skipping_current_range);
- /*
- * Normally, the fact that we can't skip this block must mean that
- * it's not all-visible. But in an aggressive vacuum we know only
- * that it's not all-frozen, so it might still be all-visible.
- */
- if (vacrel->aggressive &&
- VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
- all_visible_according_to_vm = true;
+ Assert(next_unskippable_block >= blkno + 1);
}
else
{
- /*
- * The current page can be skipped if we've seen a long enough run
- * of skippable blocks to justify skipping it -- provided it's not
- * the last page in the relation (according to rel_pages).
- *
- * We always scan the table's last page to determine whether it
- * has tuples or not, even if it would otherwise be skipped. This
- * avoids having lazy_truncate_heap() take access-exclusive lock
- * on the table to attempt a truncation that just fails
- * immediately because there are tuples on the last page.
- */
- if (skipping_blocks && blkno < rel_pages - 1)
- {
- /*
- * Tricky, tricky. If this is in aggressive vacuum, the page
- * must have been all-frozen at the time we checked whether it
- * was skippable, but it might not be any more. We must be
- * careful to count it as a skipped all-frozen page in that
- * case, or else we'll think we can't update relfrozenxid and
- * relminmxid. If it's not an aggressive vacuum, we don't
- * know whether it was initially all-frozen, so we have to
- * recheck.
- */
- if (vacrel->aggressive ||
- VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
- vacrel->frozenskipped_pages++;
- continue;
- }
+ /* Last page always scanned (may need to set nonempty_pages) */
+ Assert(blkno < rel_pages - 1);
- /*
- * SKIP_PAGES_THRESHOLD (threshold for skipping) was not
- * crossed, or this is the last page. Scan the page, even
- * though it's all-visible (and possibly even all-frozen).
- */
+ if (skipping_current_range)
+ continue;
+
+ /* Current range is too small to skip -- just scan the page */
all_visible_according_to_vm = true;
}
- vacuum_delay_point();
-
- /*
- * We're not skipping this page using the visibility map, and so it is
- * (by definition) a scanned page. Any tuples from this page are now
- * guaranteed to be counted below, after some preparatory checks.
- */
vacrel->scanned_pages++;
+ /* Report as block scanned, update error traceback information */
+ pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
+ update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
+ blkno, InvalidOffsetNumber);
+
+ vacuum_delay_point();
+
/*
* Regularly check if wraparound failsafe should trigger.
*
@@ -1241,8 +1119,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
}
/*
- * Handle setting visibility map bit based on what the VM said about
- * the page before pruning started, and using prunestate
+ * Handle setting visibility map bit based on information from the VM
+ * (as of last lazy_scan_skip() call), and from prunestate
*/
if (!all_visible_according_to_vm && prunestate.all_visible)
{
@@ -1274,9 +1152,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/*
* As of PostgreSQL 9.2, the visibility map bit should never be set if
* the page-level bit is clear. However, it's possible that the bit
- * got cleared after we checked it and before we took the buffer
- * content lock, so we must recheck before jumping to the conclusion
- * that something bad has happened.
+ * got cleared after lazy_scan_skip() was called, so we must recheck
+ * with buffer lock before concluding that the VM is corrupt.
*/
else if (all_visible_according_to_vm && !PageIsAllVisible(page)
&& VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
@@ -1315,7 +1192,7 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/*
* If the all-visible page is all-frozen but not marked as such yet,
* mark it as all-frozen. Note that all_frozen is only valid if
- * all_visible is true, so we must check both.
+ * all_visible is true, so we must check both prunestate fields.
*/
else if (all_visible_according_to_vm && prunestate.all_visible &&
prunestate.all_frozen &&
@@ -1421,6 +1298,112 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
Assert(!IsInParallelMode());
}
+/*
+ * lazy_scan_skip() -- set up range of skippable blocks using visibility map.
+ *
+ * lazy_scan_heap() calls here every time it needs to set up a new range of
+ * blocks to skip via the visibility map. Caller passes the next block in
+ * line. We return a next_unskippable_block for this range. When there are
+ * no skippable blocks we just return caller's next_block. The all-visible
+ * status of the returned block is set in *next_unskippable_allvis for caller,
+ * too. Block usually won't be all-visible (since it's unskippable), but it
+ * can be during aggressive VACUUMs (as well as in certain edge cases).
+ *
+ * Sets *skipping_current_range to indicate if caller should skip this range.
+ * Costs and benefits drive our decision. Very small ranges won't be skipped.
+ *
+ * Note: our opinion of which blocks can be skipped can go stale immediately.
+ * It's okay if caller "misses" a page whose all-visible or all-frozen marking
+ * was concurrently cleared, though. All that matters is that caller scan all
+ * pages whose tuples might contain XIDs < OldestXmin, or XMIDs < OldestMxact.
+ * (Actually, non-aggressive VACUUMs can choose to skip all-visible pages with
+ * older XIDs/MXIDs. The vacrel->skippedallvis flag will be set here when the
+ * choice to skip such a range is actually made, making everything safe.)
+ */
+static BlockNumber
+lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer, BlockNumber next_block,
+ bool *next_unskippable_allvis, bool *skipping_current_range)
+{
+ BlockNumber rel_pages = vacrel->rel_pages,
+ next_unskippable_block = next_block,
+ nskippable_blocks = 0;
+ bool allvisinrange = false;
+
+ *next_unskippable_allvis = true;
+ while (next_unskippable_block < rel_pages)
+ {
+ uint8 mapbits = visibilitymap_get_status(vacrel->rel,
+ next_unskippable_block,
+ vmbuffer);
+
+ if ((mapbits & VISIBILITYMAP_ALL_VISIBLE) == 0)
+ {
+ Assert((mapbits & VISIBILITYMAP_ALL_FROZEN) == 0);
+ *next_unskippable_allvis = false;
+ break;
+ }
+
+ /*
+ * Caller must scan the last page to determine whether it has tuples
+ * (caller must have the opportunity to set vacrel->nonempty_pages).
+ * This rule avoids having lazy_truncate_heap() take access-exclusive
+ * lock on rel to attempt a truncation that fails anyway, just because
+ * there are tuples on the last page (it is likely that there will be
+ * tuples on other nearby pages as well, but those can be skipped).
+ *
+ * Implement this by always treating the last block as unsafe to skip.
+ */
+ if (next_unskippable_block == rel_pages - 1)
+ break;
+
+ /* DISABLE_PAGE_SKIPPING makes all skipping unsafe */
+ if (!vacrel->skipwithvm)
+ break;
+
+ /*
+ * Aggressive VACUUM caller can't skip pages just because they are
+ * all-visible. They may still skip all-frozen pages, which can't
+ * contain XIDs < OldestXmin (XIDs that aren't already frozen by now).
+ */
+ if ((mapbits & VISIBILITYMAP_ALL_FROZEN) == 0)
+ {
+ if (vacrel->aggressive)
+ break;
+
+ /*
+ * All-visible block is safe to skip in non-aggressive case. But
+ * remember that the final range contains such a block for later.
+ */
+ allvisinrange = true;
+ }
+
+ vacuum_delay_point();
+ next_unskippable_block++;
+ nskippable_blocks++;
+ }
+
+ /*
+ * We only skip a range with at least SKIP_PAGES_THRESHOLD consecutive
+ * pages. Since we're reading sequentially, the OS should be doing
+ * readahead for us, so there's no gain in skipping a page now and then.
+ * Skipping such a range might even discourage sequential detection.
+ *
+ * This test also enables more frequent relfrozenxid advancement during
+ * non-aggressive VACUUMs. If the range has any all-visible pages then
+ * skipping makes updating relfrozenxid unsafe, which is a real downside.
+ */
+ if (nskippable_blocks < SKIP_PAGES_THRESHOLD)
+ *skipping_current_range = false;
+ else
+ {
+ *skipping_current_range = true;
+ if (allvisinrange)
+ vacrel->skippedallvis = true;
+ }
+
+ return next_unskippable_block;
+}
+
/*
* lazy_scan_new_or_empty() -- lazy_scan_heap() new/empty page handling.
*
--
2.32.0
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-29 17:03 Robert Haas <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Robert Haas @ 2022-03-29 17:03 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Sun, Mar 27, 2022 at 11:24 PM Peter Geoghegan <[email protected]> wrote:
> Attached is v12. My current goal is to commit all 3 patches before
> feature freeze. Note that this does not include the more complicated
> patch including with previous revisions of the patch series (the
> page-level freezing work that appeared in versions before v11).
Reviewing 0001, focusing on the words in the patch file much more than the code:
I can understand this version of the commit message. Woohoo! I like
understanding things.
I think the header comments for FreezeMultiXactId() focus way too much
on what the caller is supposed to do and not nearly enough on what
FreezeMultiXactId() itself does. I think to some extent this also
applies to the comments within the function body.
On the other hand, the header comments for heap_prepare_freeze_tuple()
seem good to me. If I were thinking of calling this function, I would
know how to use the new arguments. If I were looking for bugs in it, I
could compare the logic in the function to what these comments say it
should be doing. Yay.
I think I understand what the first paragraph of the header comment
for heap_tuple_needs_freeze() is trying to say, but the second one is
quite confusing. I think this is again because it veers into talking
about what the caller should do rather than explaining what the
function itself does.
I don't like the statement-free else block in lazy_scan_noprune(). I
think you could delete the else{} and just put that same comment there
with one less level of indentation. There's a clear "return false"
just above so it shouldn't be confusing what's happening.
The comment hunk at the end of lazy_scan_noprune() would probably be
better if it said something more specific than "caller can tolerate
reduced processing." My guess is that it would be something like
"caller does not need to do something or other."
I have my doubts about whether the overwrite-a-future-relfrozenxid
behavior is any good, but that's a topic for another day. I suggest
keeping the words "it seems best to", though, because they convey a
level of tentativeness, which seems appropriate.
I am surprised to see you write in maintenance.sgml that the VACUUM
which most recently advanced relfrozenxid will typically be the most
recent aggressive VACUUM. I would have expected something like "(often
the most recent VACUUM)".
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-29 18:58 Peter Geoghegan <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-29 18:58 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Tue, Mar 29, 2022 at 10:03 AM Robert Haas <[email protected]> wrote:
> I can understand this version of the commit message. Woohoo! I like
> understanding things.
That's good news.
> I think the header comments for FreezeMultiXactId() focus way too much
> on what the caller is supposed to do and not nearly enough on what
> FreezeMultiXactId() itself does. I think to some extent this also
> applies to the comments within the function body.
To some extent this is a legitimate difference in style. I myself
don't think that it's intrinsically good to have these sorts of
comments. I just think that it can be the least worst thing when a
function is intrinsically written with one caller and one very
specific set of requirements in mind. That is pretty much a matter of
taste, though.
> I think I understand what the first paragraph of the header comment
> for heap_tuple_needs_freeze() is trying to say, but the second one is
> quite confusing. I think this is again because it veers into talking
> about what the caller should do rather than explaining what the
> function itself does.
I wouldn't have done it that way if the function wasn't called
heap_tuple_needs_freeze().
I would be okay with removing this paragraph if the function was
renamed to reflect the fact it now tells the caller something about
the tuple having an old XID/MXID relative to the caller's own XID/MXID
cutoffs. Maybe the function name should be heap_tuple_would_freeze(),
making it clear that the function merely tells caller what
heap_prepare_freeze_tuple() *would* do, without presuming to tell the
vacuumlazy.c caller what it *should* do about any of the information
it is provided.
Then it becomes natural to see the boolean return value and the
changes the function makes to caller's relfrozenxid/relminmxid tracker
variables as independent.
> I don't like the statement-free else block in lazy_scan_noprune(). I
> think you could delete the else{} and just put that same comment there
> with one less level of indentation. There's a clear "return false"
> just above so it shouldn't be confusing what's happening.
Okay, will fix.
> The comment hunk at the end of lazy_scan_noprune() would probably be
> better if it said something more specific than "caller can tolerate
> reduced processing." My guess is that it would be something like
> "caller does not need to do something or other."
I meant "caller can tolerate not pruning or freezing this particular
page". Will fix.
> I have my doubts about whether the overwrite-a-future-relfrozenxid
> behavior is any good, but that's a topic for another day. I suggest
> keeping the words "it seems best to", though, because they convey a
> level of tentativeness, which seems appropriate.
I agree that it's best to keep a tentative tone here. That code was
written following a very specific bug in pg_upgrade several years
back. There was a very recent bug fixed only last year, by commit
74cf7d46.
FWIW I tend to think that we'd have a much better chance of catching
that sort of thing if we'd had better relfrozenxid instrumentation
before now. Now you'd see a negative value in the "new relfrozenxid:
%u, which is %d xids ahead of previous value" part of the autovacuum
log message in the event of such a bug. That's weird enough that I bet
somebody would notice and report it.
> I am surprised to see you write in maintenance.sgml that the VACUUM
> which most recently advanced relfrozenxid will typically be the most
> recent aggressive VACUUM. I would have expected something like "(often
> the most recent VACUUM)".
That's always been true, and will only be slightly less true in
Postgres 15 -- the fact is that we only need to skip one all-visible
page to lose out, and that's not unlikely with tables that aren't
quite small with all the patches from v12 applied (we're still much
too naive). The work that I'll get into Postgres 15 on VACUUM is very
valuable as a basis for future improvements, but not all that valuable
to users (improved instrumentation might be the biggest benefit in 15,
or maybe relminmxid advancement for certain types of applications).
I still think that we need to do more proactive page-level freezing to
make relfrozenxid advancement happen in almost every VACUUM, but even
that won't quite be enough. There are still cases where we need to
make a choice about giving up on relfrozenxid advancement in a
non-aggressive VACUUM -- all-visible pages won't completely go away
with page-level freezing. At a minimum we'll still have edge cases
like the case where heap_lock_tuple() unsets the all-frozen bit. And
pg_upgrade'd databases, too.
0002 structures the logic for skipping using the VM in a way that will
make the choice to skip or not skip all-visible pages in
non-aggressive VACUUMs quite natural. I suspect that
SKIP_PAGES_THRESHOLD was always mostly just about relfrozenxid
advancement in non-aggressive VACUUM, all along. We can do much better
than SKIP_PAGES_THRESHOLD, especially if we preprocess the entire
visibility map up-front -- we'll know the costs and benefits up-front,
before committing to early relfrozenxid advancement.
Overall, aggressive vs non-aggressive VACUUM seems like a false
dichotomy to me. ISTM that it should be a totally dynamic set of
behaviors. There should probably be several different "aggressive
gradations''. Most VACUUMs start out completely non-aggressive
(including even anti-wraparound autovacuums), but can escalate from
there. The non-cancellable autovacuum behavior (technically an
anti-wraparound thing, but really an aggressiveness thing) should be
something we escalate to, as with the failsafe.
Dynamic behavior works a lot better. And it makes scheduling of
autovacuum workers a lot more straightforward -- the discontinuities
seem to make that much harder, which is one more reason to avoid them
altogether.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-30 03:08 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-30 03:08 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Tue, Mar 29, 2022 at 11:58 AM Peter Geoghegan <[email protected]> wrote:
> > I think I understand what the first paragraph of the header comment
> > for heap_tuple_needs_freeze() is trying to say, but the second one is
> > quite confusing. I think this is again because it veers into talking
> > about what the caller should do rather than explaining what the
> > function itself does.
>
> I wouldn't have done it that way if the function wasn't called
> heap_tuple_needs_freeze().
>
> I would be okay with removing this paragraph if the function was
> renamed to reflect the fact it now tells the caller something about
> the tuple having an old XID/MXID relative to the caller's own XID/MXID
> cutoffs. Maybe the function name should be heap_tuple_would_freeze(),
> making it clear that the function merely tells caller what
> heap_prepare_freeze_tuple() *would* do, without presuming to tell the
> vacuumlazy.c caller what it *should* do about any of the information
> it is provided.
Attached is v13, which does it that way. This does seem like a real
increase in clarity, albeit one that comes at the cost of renaming
heap_tuple_needs_freeze().
v13 also addresses all of the other items from Robert's most recent
round of feedback.
I would like to commit something close to v13 on Friday or Saturday.
Thanks
--
Peter Geoghegan
Attachments:
[application/octet-stream] v13-0003-vacuumlazy.c-Move-resource-allocation-to-heap_va.patch (5.0K, ../../CAH2-Wz=Q2NQprVdf8wojerm-WYwy_eKmLB64mwJ25Prjf=TdvQ@mail.gmail.com/2-v13-0003-vacuumlazy.c-Move-resource-allocation-to-heap_va.patch)
download | inline diff:
From 0114ad047d7c513705421b1fcf3d2ff7fa8a001c Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 25 Mar 2022 12:51:05 -0700
Subject: [PATCH v13 3/3] vacuumlazy.c: Move resource allocation to
heap_vacuum_rel().
Finish off work started by commit 73f6ec3d: move remaining resource
allocation and deallocation code from lazy_scan_heap() to its caller,
heap_vacuum_rel().
---
src/backend/access/heap/vacuumlazy.c | 68 ++++++++++++----------------
1 file changed, 28 insertions(+), 40 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index e5c08166a..3562decf8 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -246,7 +246,7 @@ typedef struct LVSavedErrInfo
/* non-export function prototypes */
-static void lazy_scan_heap(LVRelState *vacrel, int nworkers);
+static void lazy_scan_heap(LVRelState *vacrel);
static BlockNumber lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer,
BlockNumber next_block,
bool *next_unskippable_allvis,
@@ -519,11 +519,28 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->NewRelminMxid = OldestMxact;
vacrel->skippedallvis = false;
+ /*
+ * Allocate dead_items array memory using dead_items_alloc. This handles
+ * parallel VACUUM initialization as part of allocating shared memory
+ * space used for dead_items. (But do a failsafe precheck first, to
+ * ensure that parallel VACUUM won't be attempted at all when relfrozenxid
+ * is already dangerously old.)
+ */
+ lazy_check_wraparound_failsafe(vacrel);
+ dead_items_alloc(vacrel, params->nworkers);
+
/*
* Call lazy_scan_heap to perform all required heap pruning, index
* vacuuming, and heap vacuuming (plus related processing)
*/
- lazy_scan_heap(vacrel, params->nworkers);
+ lazy_scan_heap(vacrel);
+
+ /*
+ * Free resources managed by dead_items_alloc. This ends parallel mode in
+ * passing when necessary.
+ */
+ dead_items_cleanup(vacrel);
+ Assert(!IsInParallelMode());
/*
* Update pg_class entries for each of rel's indexes where appropriate.
@@ -833,14 +850,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* supply.
*/
static void
-lazy_scan_heap(LVRelState *vacrel, int nworkers)
+lazy_scan_heap(LVRelState *vacrel)
{
- VacDeadItems *dead_items;
BlockNumber rel_pages = vacrel->rel_pages,
blkno,
next_unskippable_block,
- next_failsafe_block,
- next_fsm_block_to_vacuum;
+ next_failsafe_block = 0,
+ next_fsm_block_to_vacuum = 0;
+ VacDeadItems *dead_items = vacrel->dead_items;
Buffer vmbuffer = InvalidBuffer;
bool next_unskippable_allvis,
skipping_current_range;
@@ -851,23 +868,6 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
};
int64 initprog_val[3];
- /*
- * Do failsafe precheck before calling dead_items_alloc. This ensures
- * that parallel VACUUM won't be attempted when relfrozenxid is already
- * dangerously old.
- */
- lazy_check_wraparound_failsafe(vacrel);
- next_failsafe_block = 0;
-
- /*
- * Allocate the space for dead_items. Note that this handles parallel
- * VACUUM initialization as part of allocating shared memory space used
- * for dead_items.
- */
- dead_items_alloc(vacrel, nworkers);
- dead_items = vacrel->dead_items;
- next_fsm_block_to_vacuum = 0;
-
/* Report that we're scanning the heap, advertising total # of blocks */
initprog_val[0] = PROGRESS_VACUUM_PHASE_SCAN_HEAP;
initprog_val[1] = rel_pages;
@@ -1244,12 +1244,11 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
}
}
+ vacrel->blkno = InvalidBlockNumber;
+
/* report that everything is now scanned */
pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
- /* Clear the block number information */
- vacrel->blkno = InvalidBlockNumber;
-
/* now we can compute the new value for pg_class.reltuples */
vacrel->new_live_tuples = vac_estimate_reltuples(vacrel->rel, rel_pages,
vacrel->scanned_pages,
@@ -1264,15 +1263,11 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
vacrel->missed_dead_tuples;
/*
- * Release any remaining pin on visibility map page.
+ * Do index vacuuming (call each index's ambulkdelete routine), then do
+ * related heap vacuuming
*/
if (BufferIsValid(vmbuffer))
- {
ReleaseBuffer(vmbuffer);
- vmbuffer = InvalidBuffer;
- }
-
- /* Perform a final round of index and heap vacuuming */
if (dead_items->num_items > 0)
lazy_vacuum(vacrel);
@@ -1286,16 +1281,9 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/* report all blocks vacuumed */
pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_VACUUMED, blkno);
- /* Do post-vacuum cleanup */
+ /* Do final index cleanup (call each index's amvacuumcleanup routine) */
if (vacrel->nindexes > 0 && vacrel->do_index_cleanup)
lazy_cleanup_all_indexes(vacrel);
-
- /*
- * Free resources managed by dead_items_alloc. This ends parallel mode in
- * passing when necessary.
- */
- dead_items_cleanup(vacrel);
- Assert(!IsInParallelMode());
}
/*
--
2.32.0
[application/octet-stream] v13-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch (19.1K, ../../CAH2-Wz=Q2NQprVdf8wojerm-WYwy_eKmLB64mwJ25Prjf=TdvQ@mail.gmail.com/3-v13-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch)
download | inline diff:
From 61ad7689a0b68d1fddec3e3b7840395b7bd85a72 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v13 2/3] Generalize how VACUUM skips all-frozen pages.
Non-aggressive VACUUMs were at a gratuitous disadvantage (relative to
aggressive VACUUMs) around advancing relfrozenxid before now. The
underlying issue was that lazy_scan_heap conditioned its skipping
behavior on whether or not the current VACUUM was aggressive. VACUUM
could fail to increment its frozenskipped_pages counter as a result, and
so could miss out on advancing relfrozenxid (in the non-aggressive case)
for no good reason.
The issue only comes up when concurrent activity might unset a page's
visibility map bit at exactly the wrong time. The non-aggressive case
rechecked the visibility map at the point of skipping each page before
now. This created a window for some other session to concurrently unset
the same heap page's bit in the visibility map. If the bit was unset at
the wrong time, it would cause VACUUM to conservatively conclude that
the page was _never_ all-frozen on recheck. frozenskipped_pages would
not be incremented for the page as a result. lazy_scan_heap had already
committed to skipping the page/range at that point, though -- which made
it unsafe to advance relfrozenxid/relminmxid later on.
Consistently avoid the issue by generalizing how we skip frozen pages
during aggressive VACUUMs: take the same approach when skipping any
skippable page range during aggressive and non-aggressive VACUUMs alike.
The new approach makes ranges (not individual pages) the fundamental
unit of skipping using the visibility map. frozenskipped_pages is
replaced with a boolean flag that represents whether some skippable
range with one or more all-visible pages was actually skipped (making
relfrozenxid unsafe to update).
It is safe for VACUUM to treat a page as all-frozen provided it at least
had its all-frozen bit set after the OldestXmin cutoff was established.
VACUUM is only required to scan pages that might have XIDs < OldestXmin
that are not yet frozen to be able to safely advance relfrozenxid.
Tuples concurrently inserted on skipped pages are equivalent to tuples
concurrently inserted on a block >= rel_pages from the same table.
It's possible that the issue this commit fixes hardly ever came up in
practice. But we only had to be unlucky once to lose out on advancing
relfrozenxid -- a single affected heap page was enough to throw VACUUM
off. That seems like something to avoid on general principle. This is
similar to an issue fixed by commit 44fa8488, which taught vacuumlazy.c
to not give up on non-aggressive relfrozenxid advancement just because a
cleanup lock wasn't immediately available on some heap page.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Robert Haas <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wzn6bGJGfOy3zSTJicKLw99PHJeSOQBOViKjSCinaxUKDQ@mail.gmail.com
Discussion: https://postgr.es/m/CA+TgmobhuzSR442_cfpgxidmiRdL-GdaFSc8SD=GJcpLTx_BAw@mail.gmail.com
---
src/backend/access/heap/vacuumlazy.c | 309 +++++++++++++--------------
1 file changed, 146 insertions(+), 163 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 6cb688efc..e5c08166a 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -176,6 +176,7 @@ typedef struct LVRelState
/* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
TransactionId NewRelfrozenXid;
MultiXactId NewRelminMxid;
+ bool skippedallvis;
/* Error reporting state */
char *relnamespace;
@@ -196,7 +197,6 @@ typedef struct LVRelState
VacDeadItems *dead_items; /* TIDs whose index tuples we'll delete */
BlockNumber rel_pages; /* total number of pages */
BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
- BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber removed_pages; /* # pages removed by relation truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber missed_dead_pages; /* # pages with missed dead tuples */
@@ -247,6 +247,10 @@ typedef struct LVSavedErrInfo
/* non-export function prototypes */
static void lazy_scan_heap(LVRelState *vacrel, int nworkers);
+static BlockNumber lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer,
+ BlockNumber next_block,
+ bool *next_unskippable_allvis,
+ bool *skipping_current_range);
static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf,
BlockNumber blkno, Page page,
bool sharelock, Buffer vmbuffer);
@@ -467,7 +471,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize page counters explicitly (be tidy) */
vacrel->scanned_pages = 0;
- vacrel->frozenskipped_pages = 0;
vacrel->removed_pages = 0;
vacrel->lpdead_item_pages = 0;
vacrel->missed_dead_pages = 0;
@@ -514,6 +517,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize state used to track oldest extant XID/XMID */
vacrel->NewRelfrozenXid = OldestXmin;
vacrel->NewRelminMxid = OldestMxact;
+ vacrel->skippedallvis = false;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -569,7 +573,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
Assert(vacrel->NewRelminMxid == OldestMxact ||
MultiXactIdPrecedesOrEquals(vacrel->relminmxid,
vacrel->NewRelminMxid));
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
+ if (vacrel->skippedallvis)
{
/* Keep existing relfrozenxid and relminmxid (can't trust trackers) */
Assert(!aggressive);
@@ -838,7 +842,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
next_failsafe_block,
next_fsm_block_to_vacuum;
Buffer vmbuffer = InvalidBuffer;
- bool skipping_blocks;
+ bool next_unskippable_allvis,
+ skipping_current_range;
const int initprog_index[] = {
PROGRESS_VACUUM_PHASE,
PROGRESS_VACUUM_TOTAL_HEAP_BLKS,
@@ -869,179 +874,52 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
initprog_val[2] = dead_items->max_items;
pgstat_progress_update_multi_param(3, initprog_index, initprog_val);
- /*
- * Set things up for skipping blocks using visibility map.
- *
- * Except when vacrel->aggressive is set, we want to skip pages that are
- * all-visible according to the visibility map, but only when we can skip
- * at least SKIP_PAGES_THRESHOLD consecutive pages. Since we're reading
- * sequentially, the OS should be doing readahead for us, so there's no
- * gain in skipping a page now and then; that's likely to disable
- * readahead and so be counterproductive. Also, skipping even a single
- * page means that we can't update relfrozenxid, so we only want to do it
- * if we can skip a goodly number of pages.
- *
- * When vacrel->aggressive is set, we can't skip pages just because they
- * are all-visible, but we can still skip pages that are all-frozen, since
- * such pages do not need freezing and do not affect the value that we can
- * safely set for relfrozenxid or relminmxid.
- *
- * Before entering the main loop, establish the invariant that
- * next_unskippable_block is the next block number >= blkno that we can't
- * skip based on the visibility map, either all-visible for a regular scan
- * or all-frozen for an aggressive scan. We set it to rel_pages when
- * there's no such block. We also set up the skipping_blocks flag
- * correctly at this stage.
- *
- * Note: The value returned by visibilitymap_get_status could be slightly
- * out-of-date, since we make this test before reading the corresponding
- * heap page or locking the buffer. This is OK. If we mistakenly think
- * that the page is all-visible or all-frozen when in fact the flag's just
- * been cleared, we might fail to vacuum the page. It's easy to see that
- * skipping a page when aggressive is not set is not a very big deal; we
- * might leave some dead tuples lying around, but the next vacuum will
- * find them. But even when aggressive *is* set, it's still OK if we miss
- * a page whose all-frozen marking has just been cleared. Any new XIDs
- * just added to that page are necessarily >= vacrel->OldestXmin, and so
- * they'll have no effect on the value to which we can safely set
- * relfrozenxid. A similar argument applies for MXIDs and relminmxid.
- */
- next_unskippable_block = 0;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmstatus;
-
- vmstatus = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmstatus & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
-
- if (next_unskippable_block >= SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
-
+ /* Set up an initial range of skippable blocks using the visibility map */
+ next_unskippable_block = lazy_scan_skip(vacrel, &vmbuffer, 0,
+ &next_unskippable_allvis,
+ &skipping_current_range);
for (blkno = 0; blkno < rel_pages; blkno++)
{
Buffer buf;
Page page;
- bool all_visible_according_to_vm = false;
+ bool all_visible_according_to_vm;
LVPagePruneState prunestate;
- pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
-
- update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
- blkno, InvalidOffsetNumber);
-
if (blkno == next_unskippable_block)
{
- /* Time to advance next_unskippable_block */
- next_unskippable_block++;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmskipflags;
-
- vmskipflags = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
-
/*
- * We know we can't skip the current block. But set up
- * skipping_blocks to do the right thing at the following blocks.
+ * Can't skip this page safely. Must scan the page. But
+ * determine the next skippable range after the page first.
*/
- if (next_unskippable_block - blkno > SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
+ all_visible_according_to_vm = next_unskippable_allvis;
+ next_unskippable_block = lazy_scan_skip(vacrel, &vmbuffer,
+ blkno + 1,
+ &next_unskippable_allvis,
+ &skipping_current_range);
- /*
- * Normally, the fact that we can't skip this block must mean that
- * it's not all-visible. But in an aggressive vacuum we know only
- * that it's not all-frozen, so it might still be all-visible.
- */
- if (vacrel->aggressive &&
- VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
- all_visible_according_to_vm = true;
+ Assert(next_unskippable_block >= blkno + 1);
}
else
{
- /*
- * The current page can be skipped if we've seen a long enough run
- * of skippable blocks to justify skipping it -- provided it's not
- * the last page in the relation (according to rel_pages).
- *
- * We always scan the table's last page to determine whether it
- * has tuples or not, even if it would otherwise be skipped. This
- * avoids having lazy_truncate_heap() take access-exclusive lock
- * on the table to attempt a truncation that just fails
- * immediately because there are tuples on the last page.
- */
- if (skipping_blocks && blkno < rel_pages - 1)
- {
- /*
- * Tricky, tricky. If this is in aggressive vacuum, the page
- * must have been all-frozen at the time we checked whether it
- * was skippable, but it might not be any more. We must be
- * careful to count it as a skipped all-frozen page in that
- * case, or else we'll think we can't update relfrozenxid and
- * relminmxid. If it's not an aggressive vacuum, we don't
- * know whether it was initially all-frozen, so we have to
- * recheck.
- */
- if (vacrel->aggressive ||
- VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
- vacrel->frozenskipped_pages++;
- continue;
- }
+ /* Last page always scanned (may need to set nonempty_pages) */
+ Assert(blkno < rel_pages - 1);
- /*
- * SKIP_PAGES_THRESHOLD (threshold for skipping) was not
- * crossed, or this is the last page. Scan the page, even
- * though it's all-visible (and possibly even all-frozen).
- */
+ if (skipping_current_range)
+ continue;
+
+ /* Current range is too small to skip -- just scan the page */
all_visible_according_to_vm = true;
}
- vacuum_delay_point();
-
- /*
- * We're not skipping this page using the visibility map, and so it is
- * (by definition) a scanned page. Any tuples from this page are now
- * guaranteed to be counted below, after some preparatory checks.
- */
vacrel->scanned_pages++;
+ /* Report as block scanned, update error traceback information */
+ pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
+ update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
+ blkno, InvalidOffsetNumber);
+
+ vacuum_delay_point();
+
/*
* Regularly check if wraparound failsafe should trigger.
*
@@ -1241,8 +1119,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
}
/*
- * Handle setting visibility map bit based on what the VM said about
- * the page before pruning started, and using prunestate
+ * Handle setting visibility map bit based on information from the VM
+ * (as of last lazy_scan_skip() call), and from prunestate
*/
if (!all_visible_according_to_vm && prunestate.all_visible)
{
@@ -1274,9 +1152,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/*
* As of PostgreSQL 9.2, the visibility map bit should never be set if
* the page-level bit is clear. However, it's possible that the bit
- * got cleared after we checked it and before we took the buffer
- * content lock, so we must recheck before jumping to the conclusion
- * that something bad has happened.
+ * got cleared after lazy_scan_skip() was called, so we must recheck
+ * with buffer lock before concluding that the VM is corrupt.
*/
else if (all_visible_according_to_vm && !PageIsAllVisible(page)
&& VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
@@ -1315,7 +1192,7 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/*
* If the all-visible page is all-frozen but not marked as such yet,
* mark it as all-frozen. Note that all_frozen is only valid if
- * all_visible is true, so we must check both.
+ * all_visible is true, so we must check both prunestate fields.
*/
else if (all_visible_according_to_vm && prunestate.all_visible &&
prunestate.all_frozen &&
@@ -1421,6 +1298,112 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
Assert(!IsInParallelMode());
}
+/*
+ * lazy_scan_skip() -- set up range of skippable blocks using visibility map.
+ *
+ * lazy_scan_heap() calls here every time it needs to set up a new range of
+ * blocks to skip via the visibility map. Caller passes the next block in
+ * line. We return a next_unskippable_block for this range. When there are
+ * no skippable blocks we just return caller's next_block. The all-visible
+ * status of the returned block is set in *next_unskippable_allvis for caller,
+ * too. Block usually won't be all-visible (since it's unskippable), but it
+ * can be during aggressive VACUUMs (as well as in certain edge cases).
+ *
+ * Sets *skipping_current_range to indicate if caller should skip this range.
+ * Costs and benefits drive our decision. Very small ranges won't be skipped.
+ *
+ * Note: our opinion of which blocks can be skipped can go stale immediately.
+ * It's okay if caller "misses" a page whose all-visible or all-frozen marking
+ * was concurrently cleared, though. All that matters is that caller scan all
+ * pages whose tuples might contain XIDs < OldestXmin, or XMIDs < OldestMxact.
+ * (Actually, non-aggressive VACUUMs can choose to skip all-visible pages with
+ * older XIDs/MXIDs. The vacrel->skippedallvis flag will be set here when the
+ * choice to skip such a range is actually made, making everything safe.)
+ */
+static BlockNumber
+lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer, BlockNumber next_block,
+ bool *next_unskippable_allvis, bool *skipping_current_range)
+{
+ BlockNumber rel_pages = vacrel->rel_pages,
+ next_unskippable_block = next_block,
+ nskippable_blocks = 0;
+ bool skipsallvis = false;
+
+ *next_unskippable_allvis = true;
+ while (next_unskippable_block < rel_pages)
+ {
+ uint8 mapbits = visibilitymap_get_status(vacrel->rel,
+ next_unskippable_block,
+ vmbuffer);
+
+ if ((mapbits & VISIBILITYMAP_ALL_VISIBLE) == 0)
+ {
+ Assert((mapbits & VISIBILITYMAP_ALL_FROZEN) == 0);
+ *next_unskippable_allvis = false;
+ break;
+ }
+
+ /*
+ * Caller must scan the last page to determine whether it has tuples
+ * (caller must have the opportunity to set vacrel->nonempty_pages).
+ * This rule avoids having lazy_truncate_heap() take access-exclusive
+ * lock on rel to attempt a truncation that fails anyway, just because
+ * there are tuples on the last page (it is likely that there will be
+ * tuples on other nearby pages as well, but those can be skipped).
+ *
+ * Implement this by always treating the last block as unsafe to skip.
+ */
+ if (next_unskippable_block == rel_pages - 1)
+ break;
+
+ /* DISABLE_PAGE_SKIPPING makes all skipping unsafe */
+ if (!vacrel->skipwithvm)
+ break;
+
+ /*
+ * Aggressive VACUUM caller can't skip pages just because they are
+ * all-visible. They may still skip all-frozen pages, which can't
+ * contain XIDs < OldestXmin (XIDs that aren't already frozen by now).
+ */
+ if ((mapbits & VISIBILITYMAP_ALL_FROZEN) == 0)
+ {
+ if (vacrel->aggressive)
+ break;
+
+ /*
+ * All-visible block is safe to skip in non-aggressive case. But
+ * remember that the final range contains such a block for later.
+ */
+ skipsallvis = true;
+ }
+
+ vacuum_delay_point();
+ next_unskippable_block++;
+ nskippable_blocks++;
+ }
+
+ /*
+ * We only skip a range with at least SKIP_PAGES_THRESHOLD consecutive
+ * pages. Since we're reading sequentially, the OS should be doing
+ * readahead for us, so there's no gain in skipping a page now and then.
+ * Skipping such a range might even discourage sequential detection.
+ *
+ * This test also enables more frequent relfrozenxid advancement during
+ * non-aggressive VACUUMs. If the range has any all-visible pages then
+ * skipping makes updating relfrozenxid unsafe, which is a real downside.
+ */
+ if (nskippable_blocks < SKIP_PAGES_THRESHOLD)
+ *skipping_current_range = false;
+ else
+ {
+ *skipping_current_range = true;
+ if (skipsallvis)
+ vacrel->skippedallvis = true;
+ }
+
+ return next_unskippable_block;
+}
+
/*
* lazy_scan_new_or_empty() -- lazy_scan_heap() new/empty page handling.
*
--
2.32.0
[application/octet-stream] v13-0001-Set-relfrozenxid-to-oldest-extant-XID-seen-by-VA.patch (60.5K, ../../CAH2-Wz=Q2NQprVdf8wojerm-WYwy_eKmLB64mwJ25Prjf=TdvQ@mail.gmail.com/4-v13-0001-Set-relfrozenxid-to-oldest-extant-XID-seen-by-VA.patch)
download | inline diff:
From b62cff8f7da337be812d66623c5f6bb7e9047ba5 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v13 1/3] Set relfrozenxid to oldest extant XID seen by VACUUM.
When VACUUM set relfrozenxid before now, it set it to whatever value was
used to determine which tuples to freeze -- the FreezeLimit cutoff.
This approach was very naive: the relfrozenxid invariant only requires
that new relfrozenxid values be <= the oldest extant XID remaining in
the table (at the point that the VACUUM operation ends), which in
general might be much more recent than FreezeLimit.
VACUUM now sets relfrozenxid (and relminmxid) using the exact oldest
extant XID (and oldest extant MultiXactId) from the table, including
XIDs from the table's remaining/unfrozen MultiXacts. This requires that
VACUUM carefully track the oldest unfrozen XID/MultiXactId as it goes.
This optimization doesn't require any changes to the definition of
relfrozenxid, nor does it require changes to the core design of
freezing.
Final relfrozenxid values must still be >= FreezeLimit in an aggressive
VACUUM -- FreezeLimit still acts as a lower bound on the final value
that aggressive VACUUM can set relfrozenxid to. Since standard VACUUMs
still make no guarantees about advancing relfrozenxid, they might as
well set relfrozenxid to a value from well before FreezeLimit when the
opportunity presents itself. In general standard VACUUMs may now set
relfrozenxid to any value > the original relfrozenxid and <= OldestXmin.
Credit for the general idea of using the oldest extant XID to set
pg_class.relfrozenxid at the end of VACUUM goes to Andres Freund.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Andres Freund <[email protected]>
Reviewed-By: Robert Haas <[email protected]>
Discussion: https://postgr.es/m/CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com
---
src/include/access/heapam.h | 6 +-
src/include/access/heapam_xlog.h | 4 +-
src/include/commands/vacuum.h | 1 +
src/backend/access/heap/heapam.c | 324 +++++++++++++-----
src/backend/access/heap/vacuumlazy.c | 177 ++++++----
src/backend/commands/cluster.c | 5 +-
src/backend/commands/vacuum.c | 39 ++-
doc/src/sgml/maintenance.sgml | 30 +-
.../expected/vacuum-no-cleanup-lock.out | 189 ++++++++++
.../isolation/expected/vacuum-reltuples.out | 67 ----
src/test/isolation/isolation_schedule | 2 +-
.../specs/vacuum-no-cleanup-lock.spec | 150 ++++++++
.../isolation/specs/vacuum-reltuples.spec | 49 ---
13 files changed, 740 insertions(+), 303 deletions(-)
create mode 100644 src/test/isolation/expected/vacuum-no-cleanup-lock.out
delete mode 100644 src/test/isolation/expected/vacuum-reltuples.out
create mode 100644 src/test/isolation/specs/vacuum-no-cleanup-lock.spec
delete mode 100644 src/test/isolation/specs/vacuum-reltuples.spec
diff --git a/src/include/access/heapam.h b/src/include/access/heapam.h
index b46ab7d73..4403f01e1 100644
--- a/src/include/access/heapam.h
+++ b/src/include/access/heapam.h
@@ -167,8 +167,10 @@ extern void heap_inplace_update(Relation relation, HeapTuple tuple);
extern bool heap_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi);
-extern bool heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi);
+extern bool heap_tuple_would_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
+ MultiXactId cutoff_multi,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out);
extern bool heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple);
extern void simple_heap_insert(Relation relation, HeapTuple tup);
diff --git a/src/include/access/heapam_xlog.h b/src/include/access/heapam_xlog.h
index 5c47fdcec..2d8a7f627 100644
--- a/src/include/access/heapam_xlog.h
+++ b/src/include/access/heapam_xlog.h
@@ -410,7 +410,9 @@ extern bool heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId cutoff_xid,
TransactionId cutoff_multi,
xl_heap_freeze_tuple *frz,
- bool *totally_frozen);
+ bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out);
extern void heap_execute_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple *xlrec_tp);
extern XLogRecPtr log_heap_visible(RelFileNode rnode, Buffer heap_buffer,
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index d64f6268f..ead88edda 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -291,6 +291,7 @@ extern bool vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff);
extern bool vacuum_xid_failsafe_check(TransactionId relfrozenxid,
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 74ad445e5..c012a07ac 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -6079,10 +6079,12 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* Determine what to do during freezing when a tuple is marked by a
* MultiXactId.
*
- * NB -- this might have the side-effect of creating a new MultiXactId!
- *
* "flags" is an output value; it's used to tell caller what to do on return.
- * Possible flags are:
+ *
+ * "mxid_oldest_xid_out" is an output value; it's used to track the oldest
+ * extant Xid within any Multixact that will remain after freezing executes.
+ *
+ * Possible values that we can set in "flags":
* FRM_NOOP
* don't do anything -- keep existing Xmax
* FRM_INVALIDATE_XMAX
@@ -6094,12 +6096,17 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* FRM_RETURN_IS_MULTI
* The return value is a new MultiXactId to set as new Xmax.
* (caller must obtain proper infomask bits using GetMultiXactIdHintBits)
+ *
+ * "mxid_oldest_xid_out" is only set when "flags" contains either FRM_NOOP or
+ * FRM_RETURN_IS_MULTI, since we only leave behind a MultiXactId for these.
+ *
+ * NB: Creates a _new_ MultiXactId when FRM_RETURN_IS_MULTI is set in "flags".
*/
static TransactionId
FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, MultiXactId cutoff_multi,
- uint16 *flags)
+ uint16 *flags, TransactionId *mxid_oldest_xid_out)
{
TransactionId xid = InvalidTransactionId;
int i;
@@ -6111,6 +6118,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
bool has_lockers;
TransactionId update_xid;
bool update_committed;
+ TransactionId temp_xid_out;
*flags = 0;
@@ -6147,7 +6155,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
if (HEAP_XMAX_IS_LOCKED_ONLY(t_infomask))
{
*flags |= FRM_INVALIDATE_XMAX;
- xid = InvalidTransactionId; /* not strictly necessary */
+ xid = InvalidTransactionId;
}
else
{
@@ -6174,7 +6182,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
(errcode(ERRCODE_DATA_CORRUPTED),
errmsg_internal("cannot freeze committed update xid %u", xid)));
*flags |= FRM_INVALIDATE_XMAX;
- xid = InvalidTransactionId; /* not strictly necessary */
+ xid = InvalidTransactionId;
}
else
{
@@ -6182,6 +6190,10 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
}
}
+ /*
+ * Don't push back mxid_oldest_xid_out using FRM_RETURN_IS_XID Xid, or
+ * when no Xids will remain
+ */
return xid;
}
@@ -6205,6 +6217,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
/* is there anything older than the cutoff? */
need_replace = false;
+ temp_xid_out = *mxid_oldest_xid_out; /* init for FRM_NOOP */
for (i = 0; i < nmembers; i++)
{
if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
@@ -6212,28 +6225,38 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
need_replace = true;
break;
}
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
}
/*
* In the simplest case, there is no member older than the cutoff; we can
- * keep the existing MultiXactId as is.
+ * keep the existing MultiXactId as-is, avoiding a more expensive second
+ * pass over the multi
*/
if (!need_replace)
{
+ /*
+ * When mxid_oldest_xid_out gets pushed back here it's likely that the
+ * update Xid was the oldest member, but we don't rely on that
+ */
*flags |= FRM_NOOP;
+ *mxid_oldest_xid_out = temp_xid_out;
pfree(members);
- return InvalidTransactionId;
+ return multi;
}
/*
- * If the multi needs to be updated, figure out which members do we need
- * to keep.
+ * Do a more thorough second pass over the multi to figure out which
+ * member XIDs actually need to be kept. Checking the precise status of
+ * individual members might even show that we don't need to keep anything.
*/
nnewmembers = 0;
newmembers = palloc(sizeof(MultiXactMember) * nmembers);
has_lockers = false;
update_xid = InvalidTransactionId;
update_committed = false;
+ temp_xid_out = *mxid_oldest_xid_out; /* init for FRM_RETURN_IS_MULTI */
for (i = 0; i < nmembers; i++)
{
@@ -6289,7 +6312,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
}
/*
- * Since the tuple wasn't marked HEAPTUPLE_DEAD by vacuum, the
+ * Since the tuple wasn't totally removed when vacuum pruned, the
* update Xid cannot possibly be older than the xid cutoff. The
* presence of such a tuple would cause corruption, so be paranoid
* and check.
@@ -6302,15 +6325,20 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
update_xid, cutoff_xid)));
/*
- * If we determined that it's an Xid corresponding to an update
- * that must be retained, additionally add it to the list of
- * members of the new Multi, in case we end up using that. (We
- * might still decide to use only an update Xid and not a multi,
- * but it's easier to maintain the list as we walk the old members
- * list.)
+ * We determined that this is an Xid corresponding to an update
+ * that must be retained -- add it to new members list for later.
+ *
+ * Also consider pushing back temp_xid_out, which is needed when
+ * we later conclude that a new multi is required (i.e. when we go
+ * on to set FRM_RETURN_IS_MULTI for our caller because we also
+ * need to retain a locker that's still running).
*/
if (TransactionIdIsValid(update_xid))
+ {
newmembers[nnewmembers++] = members[i];
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
+ }
}
else
{
@@ -6318,8 +6346,18 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
if (TransactionIdIsCurrentTransactionId(members[i].xid) ||
TransactionIdIsInProgress(members[i].xid))
{
- /* running locker cannot possibly be older than the cutoff */
+ /*
+ * Running locker cannot possibly be older than the cutoff.
+ *
+ * The cutoff is <= VACUUM's OldestXmin, which is also the
+ * initial value used for top-level relfrozenxid_out tracking
+ * state. A running locker cannot be older than VACUUM's
+ * OldestXmin, either, so we don't need a temp_xid_out step.
+ */
+ Assert(TransactionIdIsNormal(members[i].xid));
Assert(!TransactionIdPrecedes(members[i].xid, cutoff_xid));
+ Assert(!TransactionIdPrecedes(members[i].xid,
+ *mxid_oldest_xid_out));
newmembers[nnewmembers++] = members[i];
has_lockers = true;
}
@@ -6328,11 +6366,16 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
pfree(members);
+ /*
+ * Determine what to do with caller's multi based on information gathered
+ * during our second pass
+ */
if (nnewmembers == 0)
{
/* nothing worth keeping!? Tell caller to remove the whole thing */
*flags |= FRM_INVALIDATE_XMAX;
xid = InvalidTransactionId;
+ /* Don't push back mxid_oldest_xid_out -- no Xids will remain */
}
else if (TransactionIdIsValid(update_xid) && !has_lockers)
{
@@ -6348,15 +6391,18 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
if (update_committed)
*flags |= FRM_MARK_COMMITTED;
xid = update_xid;
+ /* Don't push back mxid_oldest_xid_out using FRM_RETURN_IS_XID Xid */
}
else
{
/*
* Create a new multixact with the surviving members of the previous
- * one, to set as new Xmax in the tuple.
+ * one, to set as new Xmax in the tuple. The oldest surviving member
+ * might push back mxid_oldest_xid_out.
*/
xid = MultiXactIdCreateFromMembers(nnewmembers, newmembers);
*flags |= FRM_RETURN_IS_MULTI;
+ *mxid_oldest_xid_out = temp_xid_out;
}
pfree(newmembers);
@@ -6375,21 +6421,30 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* will be totally frozen after these operations are performed and false if
* more freezing will eventually be required.
*
+ * The *relfrozenxid_out and *relminmxid_out arguments are the current target
+ * relfrozenxid and relminmxid for VACUUM caller's heap rel. Any and all
+ * unfrozen XIDs or MXIDs that remain in caller's rel after VACUUM finishes
+ * _must_ have values >= the final relfrozenxid/relminmxid values in pg_class.
+ * This includes XIDs that remain as MultiXact members from any tuple's xmax.
+ * Each call here pushes back *relfrozenxid_out and/or *relminmxid_out as
+ * needed to avoid unsafe final values in rel's authoritative pg_class tuple.
+ *
* Caller is responsible for setting the offset field, if appropriate.
*
* It is assumed that the caller has checked the tuple with
* HeapTupleSatisfiesVacuum() and determined that it is not HEAPTUPLE_DEAD
* (else we should be removing the tuple, not freezing it).
*
- * NB: cutoff_xid *must* be <= the current global xmin, to ensure that any
+ * NB: This function has side effects: it might allocate a new MultiXactId.
+ * It will be set as tuple's new xmax when our *frz output is processed within
+ * heap_execute_freeze_tuple later on. If the tuple is in a shared buffer
+ * then caller had better have an exclusive lock on it already.
+ *
+ * NB: cutoff_xid *must* be <= VACUUM's OldestXmin, to ensure that any
* XID older than it could neither be running nor seen as running by any
* open transaction. This ensures that the replacement will not change
* anyone's idea of the tuple state.
- * Similarly, cutoff_multi must be less than or equal to the smallest
- * MultiXactId used by any transaction currently open.
- *
- * If the tuple is in a shared buffer, caller must hold an exclusive lock on
- * that buffer.
+ * Similarly, cutoff_multi must be <= VACUUM's OldestMxact.
*
* NB: It is not enough to set hint bits to indicate something is
* committed/invalid -- they might not be set on a standby, or after crash
@@ -6399,7 +6454,9 @@ bool
heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi,
- xl_heap_freeze_tuple *frz, bool *totally_frozen)
+ xl_heap_freeze_tuple *frz, bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out)
{
bool changed = false;
bool xmax_already_frozen = false;
@@ -6418,7 +6475,9 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* already a permanent value), while in the block below it is set true to
* mean "xmin won't need freezing after what we do to it here" (false
* otherwise). In both cases we're allowed to set totally_frozen, as far
- * as xmin is concerned.
+ * as xmin is concerned. Both cases also don't require relfrozenxid_out
+ * handling, since either way the tuple's xmin will be a permanent value
+ * once we're done with it.
*/
xid = HeapTupleHeaderGetXmin(tuple);
if (!TransactionIdIsNormal(xid))
@@ -6443,6 +6502,12 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
frz->t_infomask |= HEAP_XMIN_FROZEN;
changed = true;
}
+ else
+ {
+ /* xmin to remain unfrozen. Could push back relfrozenxid_out. */
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ }
}
/*
@@ -6452,7 +6517,7 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* freezing, too. Also, if a multi needs freezing, we cannot simply take
* it out --- if there's a live updater Xid, it needs to be kept.
*
- * Make sure to keep heap_tuple_needs_freeze in sync with this.
+ * Make sure to keep heap_tuple_would_freeze in sync with this.
*/
xid = HeapTupleHeaderGetRawXmax(tuple);
@@ -6460,15 +6525,28 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
{
TransactionId newxmax;
uint16 flags;
+ TransactionId mxid_oldest_xid_out = *relfrozenxid_out;
newxmax = FreezeMultiXactId(xid, tuple->t_infomask,
relfrozenxid, relminmxid,
- cutoff_xid, cutoff_multi, &flags);
+ cutoff_xid, cutoff_multi,
+ &flags, &mxid_oldest_xid_out);
freeze_xmax = (flags & FRM_INVALIDATE_XMAX);
if (flags & FRM_RETURN_IS_XID)
{
+ /*
+ * xmax will become an updater Xid (original MultiXact's updater
+ * member Xid will be carried forward as a simple Xid in Xmax).
+ * Might have to ratchet back relfrozenxid_out here, though never
+ * relminmxid_out.
+ */
+ Assert(!freeze_xmax);
+ Assert(TransactionIdIsValid(newxmax));
+ if (TransactionIdPrecedes(newxmax, *relfrozenxid_out))
+ *relfrozenxid_out = newxmax;
+
/*
* NB -- some of these transformations are only valid because we
* know the return Xid is a tuple updater (i.e. not merely a
@@ -6487,6 +6565,19 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
uint16 newbits;
uint16 newbits2;
+ /*
+ * xmax is an old MultiXactId that we have to replace with a new
+ * MultiXactId, to carry forward two or more original member XIDs.
+ * Might have to ratchet back relfrozenxid_out here, though never
+ * relminmxid_out.
+ */
+ Assert(!freeze_xmax);
+ Assert(MultiXactIdIsValid(newxmax));
+ Assert(!MultiXactIdPrecedes(newxmax, *relminmxid_out));
+ Assert(TransactionIdPrecedesOrEquals(mxid_oldest_xid_out,
+ *relfrozenxid_out));
+ *relfrozenxid_out = mxid_oldest_xid_out;
+
/*
* We can't use GetMultiXactIdHintBits directly on the new multi
* here; that routine initializes the masks to all zeroes, which
@@ -6503,6 +6594,30 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
changed = true;
}
+ else if (flags & FRM_NOOP)
+ {
+ /*
+ * xmax is a MultiXactId, and nothing about it changes for now.
+ * Might have to ratchet back relminmxid_out, relfrozenxid_out, or
+ * both together.
+ */
+ Assert(!freeze_xmax);
+ Assert(MultiXactIdIsValid(newxmax) && xid == newxmax);
+ Assert(TransactionIdPrecedesOrEquals(mxid_oldest_xid_out,
+ *relfrozenxid_out));
+ if (MultiXactIdPrecedes(xid, *relminmxid_out))
+ *relminmxid_out = xid;
+ *relfrozenxid_out = mxid_oldest_xid_out;
+ }
+ else
+ {
+ /*
+ * Keeping nothing (neither an Xid nor a MultiXactId) in xmax.
+ * Won't have to ratchet back relminmxid_out or relfrozenxid_out.
+ */
+ Assert(freeze_xmax);
+ Assert(!TransactionIdIsValid(newxmax));
+ }
}
else if (TransactionIdIsNormal(xid))
{
@@ -6527,15 +6642,21 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
errmsg_internal("cannot freeze committed xmax %u",
xid)));
freeze_xmax = true;
+ /* No need for relfrozenxid_out handling, since we'll freeze xmax */
}
else
+ {
freeze_xmax = false;
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ }
}
else if ((tuple->t_infomask & HEAP_XMAX_INVALID) ||
!TransactionIdIsValid(HeapTupleHeaderGetRawXmax(tuple)))
{
freeze_xmax = false;
xmax_already_frozen = true;
+ /* No need for relfrozenxid_out handling for already-frozen xmax */
}
else
ereport(ERROR,
@@ -6576,6 +6697,8 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* was removed in PostgreSQL 9.0. Note that if we were to respect
* cutoff_xid here, we'd need to make surely to clear totally_frozen
* when we skipped freezing on that basis.
+ *
+ * No need for relfrozenxid_out handling, since we always freeze xvac.
*/
if (TransactionIdIsNormal(xid))
{
@@ -6653,11 +6776,14 @@ heap_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple frz;
bool do_freeze;
bool tuple_totally_frozen;
+ TransactionId relfrozenxid_out = cutoff_xid;
+ MultiXactId relminmxid_out = cutoff_multi;
do_freeze = heap_prepare_freeze_tuple(tuple,
relfrozenxid, relminmxid,
cutoff_xid, cutoff_multi,
- &frz, &tuple_totally_frozen);
+ &frz, &tuple_totally_frozen,
+ &relfrozenxid_out, &relminmxid_out);
/*
* Note that because this is not a WAL-logged operation, we don't need to
@@ -7036,9 +7162,7 @@ ConditionalMultiXactIdWait(MultiXactId multi, MultiXactStatus status,
* heap_tuple_needs_eventual_freeze
*
* Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
- * will eventually require freezing. Similar to heap_tuple_needs_freeze,
- * but there's no cutoff, since we're trying to figure out whether freezing
- * will ever be needed, not whether it's needed now.
+ * will eventually require freezing (if tuple isn't removed before then).
*/
bool
heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
@@ -7082,87 +7206,109 @@ heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
}
/*
- * heap_tuple_needs_freeze
+ * heap_tuple_would_freeze
*
- * Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
- * are older than the specified cutoff XID or MultiXactId. If so, return true.
+ * Return value indicates if heap_prepare_freeze_tuple sibling function would
+ * freeze any of the XID/XMID fields from the tuple, given the same cutoffs.
+ * We must also deal with dead tuples here, since (xmin, xmax, xvac) fields
+ * could be processed by pruning away the whole tuple (instead of freezing).
*
- * It doesn't matter whether the tuple is alive or dead, we are checking
- * to see if a tuple needs to be removed or frozen to avoid wraparound.
+ * The *relfrozenxid_out and *relminmxid_out input/output arguments work just
+ * like the heap_prepare_freeze_tuple arguments that they're based on. We
+ * never freeze here, which makes tracking the oldest extant XID/MXID simple.
*
* NB: Cannot rely on hint bits here, they might not be set after a crash or
* on a standby.
*/
bool
-heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi)
+heap_tuple_would_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
+ MultiXactId cutoff_multi,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out)
{
+ bool would_freeze = false;
TransactionId xid;
+ MultiXactId multi;
+ /* First deal with xmin */
xid = HeapTupleHeaderGetXmin(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
-
- /*
- * The considerations for multixacts are complicated; look at
- * heap_prepare_freeze_tuple for justifications. This routine had better
- * be in sync with that one!
- */
- if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
+ if (TransactionIdIsNormal(xid))
{
- MultiXactId multi;
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ would_freeze = true;
+ }
+ /* Now deal with xmax */
+ xid = InvalidTransactionId;
+ multi = InvalidMultiXactId;
+ if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
multi = HeapTupleHeaderGetRawXmax(tuple);
- if (!MultiXactIdIsValid(multi))
- {
- /* no xmax set, ignore */
- ;
- }
- else if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
- return true;
- else if (MultiXactIdPrecedes(multi, cutoff_multi))
- return true;
- else
- {
- MultiXactMember *members;
- int nmembers;
- int i;
+ else
+ xid = HeapTupleHeaderGetRawXmax(tuple);
- /* need to check whether any member of the mxact is too old */
-
- nmembers = GetMultiXactIdMembers(multi, &members, false,
- HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
-
- for (i = 0; i < nmembers; i++)
- {
- if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
- {
- pfree(members);
- return true;
- }
- }
- if (nmembers > 0)
- pfree(members);
- }
+ if (TransactionIdIsNormal(xid))
+ {
+ /* xmax is a non-permanent XID */
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ would_freeze = true;
+ }
+ else if (!MultiXactIdIsValid(multi))
+ {
+ /* xmax is a permanent XID or invalid MultiXactId/XID */
+ }
+ else if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
+ {
+ /* xmax is a pg_upgrade'd MultiXact, which can't have updater XID */
+ if (MultiXactIdPrecedes(multi, *relminmxid_out))
+ *relminmxid_out = multi;
+ /* heap_prepare_freeze_tuple always freezes pg_upgrade'd xmax */
+ would_freeze = true;
}
else
{
- xid = HeapTupleHeaderGetRawXmax(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ /* xmax is a MultiXactId that may have an updater XID */
+ MultiXactMember *members;
+ int nmembers;
+
+ if (MultiXactIdPrecedes(multi, *relminmxid_out))
+ *relminmxid_out = multi;
+ if (MultiXactIdPrecedes(multi, cutoff_multi))
+ would_freeze = true;
+
+ /* need to check whether any member of the mxact is old */
+ nmembers = GetMultiXactIdMembers(multi, &members, false,
+ HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
+
+ for (int i = 0; i < nmembers; i++)
+ {
+ xid = members[i].xid;
+ Assert(TransactionIdIsNormal(xid));
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ would_freeze = true;
+ }
+ if (nmembers > 0)
+ pfree(members);
}
if (tuple->t_infomask & HEAP_MOVED)
{
xid = HeapTupleHeaderGetXvac(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ /* heap_prepare_freeze_tuple always freezes xvac */
+ would_freeze = true;
+ }
}
- return false;
+ return would_freeze;
}
/*
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 87ab7775a..6cb688efc 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -144,7 +144,7 @@ typedef struct LVRelState
Relation *indrels;
int nindexes;
- /* Aggressive VACUUM (scan all unfrozen pages)? */
+ /* Aggressive VACUUM? (must set relfrozenxid >= FreezeLimit) */
bool aggressive;
/* Use visibility map to skip? (disabled by DISABLE_PAGE_SKIPPING) */
bool skipwithvm;
@@ -173,8 +173,9 @@ typedef struct LVRelState
/* VACUUM operation's target cutoffs for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
- /* Are FreezeLimit/MultiXactCutoff still valid? */
- bool freeze_cutoffs_valid;
+ /* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
/* Error reporting state */
char *relnamespace;
@@ -319,17 +320,17 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
skipwithvm;
bool frozenxid_updated,
minmulti_updated;
- BlockNumber orig_rel_pages;
+ BlockNumber orig_rel_pages,
+ new_rel_pages,
+ new_rel_allvisible;
char **indnames = NULL;
- BlockNumber new_rel_pages;
- BlockNumber new_rel_allvisible;
- double new_live_tuples;
ErrorContextCallback errcallback;
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
- TransactionId OldestXmin;
- TransactionId FreezeLimit;
- MultiXactId MultiXactCutoff;
+ TransactionId OldestXmin,
+ FreezeLimit;
+ MultiXactId OldestMxact,
+ MultiXactCutoff;
verbose = (params->options & VACOPT_VERBOSE) != 0;
instrument = (verbose || (IsAutoVacuumWorkerProcess() &&
@@ -351,20 +352,17 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/*
* Get OldestXmin cutoff, which is used to determine which deleted tuples
* are considered DEAD, not just RECENTLY_DEAD. Also get related cutoffs
- * used to determine which XIDs/MultiXactIds will be frozen.
- *
- * If this is an aggressive VACUUM, then we're strictly required to freeze
- * any and all XIDs from before FreezeLimit, so that we will be able to
- * safely advance relfrozenxid up to FreezeLimit below (we must be able to
- * advance relminmxid up to MultiXactCutoff, too).
+ * used to determine which XIDs/MultiXactIds will be frozen. If this is
+ * an aggressive VACUUM then lazy_scan_heap cannot leave behind unfrozen
+ * XIDs < FreezeLimit (or unfrozen MXIDs < MultiXactCutoff).
*/
aggressive = vacuum_set_xid_limits(rel,
params->freeze_min_age,
params->freeze_table_age,
params->multixact_freeze_min_age,
params->multixact_freeze_table_age,
- &OldestXmin, &FreezeLimit,
- &MultiXactCutoff);
+ &OldestXmin, &OldestMxact,
+ &FreezeLimit, &MultiXactCutoff);
skipwithvm = true;
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
@@ -511,10 +509,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->vistest = GlobalVisTestFor(rel);
/* FreezeLimit controls XID freezing (always <= OldestXmin) */
vacrel->FreezeLimit = FreezeLimit;
- /* MultiXactCutoff controls MXID freezing */
+ /* MultiXactCutoff controls MXID freezing (always <= OldestMxact) */
vacrel->MultiXactCutoff = MultiXactCutoff;
- /* Track if cutoffs became invalid (possible in !aggressive case only) */
- vacrel->freeze_cutoffs_valid = true;
+ /* Initialize state used to track oldest extant XID/XMID */
+ vacrel->NewRelfrozenXid = OldestXmin;
+ vacrel->NewRelminMxid = OldestMxact;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -548,16 +547,41 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/*
* Prepare to update rel's pg_class entry.
*
- * In principle new_live_tuples could be -1 indicating that we (still)
- * don't know the tuple count. In practice that probably can't happen,
- * since we'd surely have scanned some pages if the table is new and
- * nonempty.
- *
+ * Aggressive VACUUMs must advance relfrozenxid to a value >= FreezeLimit,
+ * and advance relminmxid to a value >= MultiXactCutoff.
+ */
+ Assert(!aggressive || vacrel->NewRelfrozenXid == OldestXmin ||
+ TransactionIdPrecedesOrEquals(FreezeLimit,
+ vacrel->NewRelfrozenXid));
+ Assert(!aggressive || vacrel->NewRelminMxid == OldestMxact ||
+ MultiXactIdPrecedesOrEquals(MultiXactCutoff,
+ vacrel->NewRelminMxid));
+
+ /*
+ * Non-aggressive VACUUMs might advance relfrozenxid to an XID that is
+ * either older or newer than FreezeLimit (same applies to relminmxid and
+ * MultiXactCutoff). But the state that tracks the oldest remaining XID
+ * and MXID cannot be trusted when any all-visible pages were skipped.
+ */
+ Assert(vacrel->NewRelfrozenXid == OldestXmin ||
+ TransactionIdPrecedesOrEquals(vacrel->relfrozenxid,
+ vacrel->NewRelfrozenXid));
+ Assert(vacrel->NewRelminMxid == OldestMxact ||
+ MultiXactIdPrecedesOrEquals(vacrel->relminmxid,
+ vacrel->NewRelminMxid));
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
+ {
+ /* Keep existing relfrozenxid and relminmxid (can't trust trackers) */
+ Assert(!aggressive);
+ vacrel->NewRelfrozenXid = InvalidTransactionId;
+ vacrel->NewRelminMxid = InvalidMultiXactId;
+ }
+
+ /*
* For safety, clamp relallvisible to be not more than what we're setting
- * relpages to.
+ * pg_class.relpages to
*/
new_rel_pages = vacrel->rel_pages; /* After possible rel truncation */
- new_live_tuples = vacrel->new_live_tuples;
visibilitymap_count(rel, &new_rel_allvisible, NULL);
if (new_rel_allvisible > new_rel_pages)
new_rel_allvisible = new_rel_pages;
@@ -565,33 +589,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/*
* Now actually update rel's pg_class entry.
*
- * Aggressive VACUUM must reliably advance relfrozenxid (and relminmxid).
- * We are able to advance relfrozenxid in a non-aggressive VACUUM too,
- * provided we didn't skip any all-visible (not all-frozen) pages using
- * the visibility map, and assuming that we didn't fail to get a cleanup
- * lock that made it unsafe with respect to FreezeLimit (or perhaps our
- * MultiXactCutoff) established for VACUUM operation.
+ * In principle new_live_tuples could be -1 indicating that we (still)
+ * don't know the tuple count. In practice that can't happen, since we
+ * scan every page that isn't skipped using the visibility map.
*/
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
- !vacrel->freeze_cutoffs_valid)
- {
- /* Cannot advance relfrozenxid/relminmxid */
- Assert(!aggressive);
- frozenxid_updated = minmulti_updated = false;
- vac_update_relstats(rel, new_rel_pages, new_live_tuples,
- new_rel_allvisible, vacrel->nindexes > 0,
- InvalidTransactionId, InvalidMultiXactId,
- NULL, NULL, false);
- }
- else
- {
- Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
- orig_rel_pages);
- vac_update_relstats(rel, new_rel_pages, new_live_tuples,
- new_rel_allvisible, vacrel->nindexes > 0,
- FreezeLimit, MultiXactCutoff,
- &frozenxid_updated, &minmulti_updated, false);
- }
+ vac_update_relstats(rel, new_rel_pages, vacrel->new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ vacrel->NewRelfrozenXid, vacrel->NewRelminMxid,
+ &frozenxid_updated, &minmulti_updated, false);
/*
* Report results to the stats collector, too.
@@ -605,7 +610,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
*/
pgstat_report_vacuum(RelationGetRelid(rel),
rel->rd_rel->relisshared,
- Max(new_live_tuples, 0),
+ Max(vacrel->new_live_tuples, 0),
vacrel->recently_dead_tuples +
vacrel->missed_dead_tuples);
pgstat_progress_end_command();
@@ -694,17 +699,19 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
OldestXmin, diff);
if (frozenxid_updated)
{
- diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
+ diff = (int32) (vacrel->NewRelfrozenXid - vacrel->relfrozenxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relfrozenxid: %u, which is %d xids ahead of previous value\n"),
- FreezeLimit, diff);
+ vacrel->NewRelfrozenXid, diff);
}
if (minmulti_updated)
{
- diff = (int32) (MultiXactCutoff - vacrel->relminmxid);
+ diff = (int32) (vacrel->NewRelminMxid - vacrel->relminmxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relminmxid: %u, which is %d mxids ahead of previous value\n"),
- MultiXactCutoff, diff);
+ vacrel->NewRelminMxid, diff);
}
if (orig_rel_pages > 0)
{
@@ -1584,6 +1591,8 @@ lazy_scan_prune(LVRelState *vacrel,
recently_dead_tuples;
int nnewlpdead;
int nfrozen;
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
@@ -1593,7 +1602,9 @@ lazy_scan_prune(LVRelState *vacrel,
retry:
- /* Initialize (or reset) page-level counters */
+ /* Initialize (or reset) page-level state */
+ NewRelfrozenXid = vacrel->NewRelfrozenXid;
+ NewRelminMxid = vacrel->NewRelminMxid;
tuples_deleted = 0;
lpdead_items = 0;
live_tuples = 0;
@@ -1801,7 +1812,8 @@ retry:
vacrel->FreezeLimit,
vacrel->MultiXactCutoff,
&frozen[nfrozen],
- &tuple_totally_frozen))
+ &tuple_totally_frozen,
+ &NewRelfrozenXid, &NewRelminMxid))
{
/* Will execute freeze below */
frozen[nfrozen++].offset = offnum;
@@ -1815,13 +1827,16 @@ retry:
prunestate->all_frozen = false;
}
+ vacrel->offnum = InvalidOffsetNumber;
+
/*
* We have now divided every item on the page into either an LP_DEAD item
* that will need to be vacuumed in indexes later, or a LP_NORMAL tuple
* that remains and needs to be considered for freezing now (LP_UNUSED and
* LP_REDIRECT items also remain, but are of no further interest to us).
*/
- vacrel->offnum = InvalidOffsetNumber;
+ vacrel->NewRelfrozenXid = NewRelfrozenXid;
+ vacrel->NewRelminMxid = NewRelminMxid;
/*
* Consider the need to freeze any items with tuple storage from the page
@@ -1971,6 +1986,8 @@ lazy_scan_noprune(LVRelState *vacrel,
recently_dead_tuples,
missed_dead_tuples;
HeapTupleHeader tupleheader;
+ TransactionId NewRelfrozenXid = vacrel->NewRelfrozenXid;
+ MultiXactId NewRelminMxid = vacrel->NewRelminMxid;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
Assert(BufferGetBlockNumber(buf) == blkno);
@@ -2015,22 +2032,37 @@ lazy_scan_noprune(LVRelState *vacrel,
*hastup = true; /* page prevents rel truncation */
tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
- if (heap_tuple_needs_freeze(tupleheader,
+ if (heap_tuple_would_freeze(tupleheader,
vacrel->FreezeLimit,
- vacrel->MultiXactCutoff))
+ vacrel->MultiXactCutoff,
+ &NewRelfrozenXid, &NewRelminMxid))
{
+ /* Tuple with XID < FreezeLimit (or MXID < MultiXactCutoff) */
if (vacrel->aggressive)
{
- /* Going to have to get cleanup lock for lazy_scan_prune */
+ /*
+ * Aggressive VACUUMs must always be able to advance rel's
+ * relfrozenxid to a value >= FreezeLimit (and be able to
+ * advance rel's relminmxid to a value >= MultiXactCutoff).
+ * The ongoing aggressive VACUUM won't be able to do that
+ * unless it can freezes an XID (or XMID) from this tuple now.
+ *
+ * The only safe option is to have caller perform processing
+ * of this page using lazy_scan_prune. Caller might have to
+ * wait a while for a cleanup lock, but it can't be helped.
+ */
vacrel->offnum = InvalidOffsetNumber;
return false;
}
/*
- * Current non-aggressive VACUUM operation definitely won't be
- * able to advance relfrozenxid or relminmxid
+ * Non-aggressive VACUUMs are under no strict obligated to advance
+ * relfrozenxid (not even by one XID). We can be much laxer here.
+ *
+ * Currently we always just accept an older final relfrozenxid
+ * and/or relminmxid value. We never make caller wait or work a
+ * little harder, even when it likely makes sense to do so.
*/
- vacrel->freeze_cutoffs_valid = false;
}
ItemPointerSet(&(tuple.t_self), blkno, offnum);
@@ -2080,9 +2112,14 @@ lazy_scan_noprune(LVRelState *vacrel,
vacrel->offnum = InvalidOffsetNumber;
/*
- * Now save details of the LP_DEAD items from the page in vacrel (though
- * only when VACUUM uses two-pass strategy)
+ * By here we know for sure that caller can put off freezing and pruning
+ * this particular page until the next VACUUM. Remember its details now.
+ * (lazy_scan_prune expects a clean slate, so we have to do this last.)
*/
+ vacrel->NewRelfrozenXid = NewRelfrozenXid;
+ vacrel->NewRelminMxid = NewRelminMxid;
+
+ /* Save details of the LP_DEAD items from the page */
if (vacrel->nindexes == 0)
{
/* Using one-pass strategy (since table has no indexes) */
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c
index 02a7e94bf..a7e988298 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/cluster.c
@@ -767,6 +767,7 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
TupleDesc oldTupDesc PG_USED_FOR_ASSERTS_ONLY;
TupleDesc newTupDesc PG_USED_FOR_ASSERTS_ONLY;
TransactionId OldestXmin;
+ MultiXactId oldestMxact;
TransactionId FreezeXid;
MultiXactId MultiXactCutoff;
bool use_sort;
@@ -856,8 +857,8 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
* Since we're going to rewrite the whole table anyway, there's no reason
* not to be aggressive about this.
*/
- vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0,
- &OldestXmin, &FreezeXid, &MultiXactCutoff);
+ vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0, &OldestXmin, &oldestMxact,
+ &FreezeXid, &MultiXactCutoff);
/*
* FreezeXid will become the table's new relfrozenxid, and that mustn't go
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 50a4a612e..3ff08a2a1 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -945,14 +945,22 @@ get_all_vacuum_rels(int options)
* The output parameters are:
* - oldestXmin is the Xid below which tuples deleted by any xact (that
* committed) should be considered DEAD, not just RECENTLY_DEAD.
- * - freezeLimit is the Xid below which all Xids are replaced by
- * FrozenTransactionId during vacuum.
- * - multiXactCutoff is the value below which all MultiXactIds are removed
- * from Xmax.
+ * - oldestMxact is the Mxid below which MultiXacts are definitely not
+ * seen as visible by any running transaction.
+ * - freezeLimit is the Xid below which all Xids are definitely replaced by
+ * FrozenTransactionId during aggressive vacuums.
+ * - multiXactCutoff is the value below which all MultiXactIds are definitely
+ * removed from Xmax during aggressive vacuums.
*
* Return value indicates if vacuumlazy.c caller should make its VACUUM
* operation aggressive. An aggressive VACUUM must advance relfrozenxid up to
- * FreezeLimit, and relminmxid up to multiXactCutoff.
+ * FreezeLimit (at a minimum), and relminmxid up to multiXactCutoff (at a
+ * minimum).
+ *
+ * oldestXmin and oldestMxact are the most recent values that can ever be
+ * passed to vac_update_relstats() as frozenxid and minmulti arguments by our
+ * vacuumlazy.c caller later on. These values should be passed when it turns
+ * out that VACUUM will leave no unfrozen XIDs/XMIDs behind in the table.
*/
bool
vacuum_set_xid_limits(Relation rel,
@@ -961,6 +969,7 @@ vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff)
{
@@ -969,7 +978,6 @@ vacuum_set_xid_limits(Relation rel,
int effective_multixact_freeze_max_age;
TransactionId limit;
TransactionId safeLimit;
- MultiXactId oldestMxact;
MultiXactId mxactLimit;
MultiXactId safeMxactLimit;
int freezetable;
@@ -1065,9 +1073,11 @@ vacuum_set_xid_limits(Relation rel,
effective_multixact_freeze_max_age / 2);
Assert(mxid_freezemin >= 0);
+ /* Remember for caller */
+ *oldestMxact = GetOldestMultiXactId();
+
/* compute the cutoff multi, being careful to generate a valid value */
- oldestMxact = GetOldestMultiXactId();
- mxactLimit = oldestMxact - mxid_freezemin;
+ mxactLimit = *oldestMxact - mxid_freezemin;
if (mxactLimit < FirstMultiXactId)
mxactLimit = FirstMultiXactId;
@@ -1082,8 +1092,8 @@ vacuum_set_xid_limits(Relation rel,
(errmsg("oldest multixact is far in the past"),
errhint("Close open transactions with multixacts soon to avoid wraparound problems.")));
/* Use the safe limit, unless an older mxact is still running */
- if (MultiXactIdPrecedes(oldestMxact, safeMxactLimit))
- mxactLimit = oldestMxact;
+ if (MultiXactIdPrecedes(*oldestMxact, safeMxactLimit))
+ mxactLimit = *oldestMxact;
else
mxactLimit = safeMxactLimit;
}
@@ -1390,12 +1400,9 @@ vac_update_relstats(Relation relation,
* Update relfrozenxid, unless caller passed InvalidTransactionId
* indicating it has no new data.
*
- * Ordinarily, we don't let relfrozenxid go backwards: if things are
- * working correctly, the only way the new frozenxid could be older would
- * be if a previous VACUUM was done with a tighter freeze_min_age, in
- * which case we don't want to forget the work it already did. However,
- * if the stored relfrozenxid is "in the future", then it must be corrupt
- * and it seems best to overwrite it with the cutoff we used this time.
+ * Ordinarily, we don't let relfrozenxid go backwards. However, if the
+ * stored relfrozenxid is "in the future" then it must be corrupt. Seems
+ * best to overwrite it with the oldest extant XID left behind by VACUUM.
* This should match vac_update_datfrozenxid() concerning what we consider
* to be "in the future".
*/
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 34d72dba7..0a7b38c17 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -585,9 +585,11 @@
statistics in the system tables <structname>pg_class</structname> and
<structname>pg_database</structname>. In particular,
the <structfield>relfrozenxid</structfield> column of a table's
- <structname>pg_class</structname> row contains the freeze cutoff XID that was used
- by the last aggressive <command>VACUUM</command> for that table. All rows
- inserted by transactions with XIDs older than this cutoff XID are
+ <structname>pg_class</structname> row contains the oldest
+ remaining XID at the end of the most recent <command>VACUUM</command>
+ that successfully advanced <structfield>relfrozenxid</structfield>
+ (typically the most recent aggressive VACUUM). All rows inserted
+ by transactions with XIDs older than this cutoff XID are
guaranteed to have been frozen. Similarly,
the <structfield>datfrozenxid</structfield> column of a database's
<structname>pg_database</structname> row is a lower bound on the unfrozen XIDs
@@ -610,6 +612,17 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
cutoff XID to the current transaction's XID.
</para>
+ <tip>
+ <para>
+ <literal>VACUUM VERBOSE</literal> outputs information about
+ <structfield>relfrozenxid</structfield> and/or
+ <structfield>relminmxid</structfield> when either field was
+ advanced. The same details appear in the server log when <xref
+ linkend="guc-log-autovacuum-min-duration"/> reports on vacuuming
+ by autovacuum.
+ </para>
+ </tip>
+
<para>
<command>VACUUM</command> normally only scans pages that have been modified
since the last vacuum, but <structfield>relfrozenxid</structfield> can only be
@@ -624,7 +637,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
set <literal>age(relfrozenxid)</literal> to a value just a little more than the
<varname>vacuum_freeze_min_age</varname> setting
that was used (more by the number of transactions started since the
- <command>VACUUM</command> started). If no <structfield>relfrozenxid</structfield>-advancing
+ <command>VACUUM</command> started). <command>VACUUM</command>
+ will set <structfield>relfrozenxid</structfield> to the oldest XID
+ that remains in the table, so it's possible that the final value
+ will be much more recent than strictly required.
+ If no <structfield>relfrozenxid</structfield>-advancing
<command>VACUUM</command> is issued on the table until
<varname>autovacuum_freeze_max_age</varname> is reached, an autovacuum will soon
be forced for the table.
@@ -711,8 +728,9 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
</para>
<para>
- Aggressive <command>VACUUM</command> scans, regardless of
- what causes them, enable advancing the value for that table.
+ Aggressive <command>VACUUM</command> scans, regardless of what
+ causes them, are <emphasis>guaranteed</emphasis> to be able to
+ advance the table's <structfield>relminmxid</structfield>.
Eventually, as all tables in all databases are scanned and their
oldest multixact values are advanced, on-disk storage for older
multixacts can be removed.
diff --git a/src/test/isolation/expected/vacuum-no-cleanup-lock.out b/src/test/isolation/expected/vacuum-no-cleanup-lock.out
new file mode 100644
index 000000000..f7bc93e8f
--- /dev/null
+++ b/src/test/isolation/expected/vacuum-no-cleanup-lock.out
@@ -0,0 +1,189 @@
+Parsed test spec with 4 sessions
+
+starting permutation: vacuumer_pg_class_stats dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+
+starting permutation: vacuumer_pg_class_stats dml_insert pinholder_cursor vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: vacuumer_pg_class_stats pinholder_cursor dml_insert dml_delete dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step dml_delete:
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: vacuumer_pg_class_stats dml_insert dml_delete pinholder_cursor dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step dml_delete:
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: dml_begin dml_other_begin dml_key_share dml_other_key_share vacuumer_nonaggressive_vacuum pinholder_cursor dml_other_update dml_commit dml_other_commit vacuumer_nonaggressive_vacuum pinholder_commit vacuumer_nonaggressive_vacuum
+step dml_begin: BEGIN;
+step dml_other_begin: BEGIN;
+step dml_key_share: SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE;
+id
+--
+ 3
+(1 row)
+
+step dml_other_key_share: SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE;
+id
+--
+ 3
+(1 row)
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_other_update: UPDATE smalltbl SET t = 'u' WHERE id = 3;
+step dml_commit: COMMIT;
+step dml_other_commit: COMMIT;
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step pinholder_commit:
+ COMMIT;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
diff --git a/src/test/isolation/expected/vacuum-reltuples.out b/src/test/isolation/expected/vacuum-reltuples.out
deleted file mode 100644
index ce55376e7..000000000
--- a/src/test/isolation/expected/vacuum-reltuples.out
+++ /dev/null
@@ -1,67 +0,0 @@
-Parsed test spec with 2 sessions
-
-starting permutation: modify vac stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step vac:
- vacuum smalltbl;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
-
-starting permutation: modify open fetch1 vac close stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step open:
- begin;
- declare c1 cursor for select 1 as dummy from smalltbl;
-
-step fetch1:
- fetch next from c1;
-
-dummy
------
- 1
-(1 row)
-
-step vac:
- vacuum smalltbl;
-
-step close:
- commit;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
-
-starting permutation: modify vac stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step vac:
- vacuum smalltbl;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
diff --git a/src/test/isolation/isolation_schedule b/src/test/isolation/isolation_schedule
index 00749a40b..a48caae22 100644
--- a/src/test/isolation/isolation_schedule
+++ b/src/test/isolation/isolation_schedule
@@ -84,7 +84,7 @@ test: alter-table-4
test: create-trigger
test: sequence-ddl
test: async-notify
-test: vacuum-reltuples
+test: vacuum-no-cleanup-lock
test: timeouts
test: vacuum-concurrent-drop
test: vacuum-conflict
diff --git a/src/test/isolation/specs/vacuum-no-cleanup-lock.spec b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec
new file mode 100644
index 000000000..a88be66de
--- /dev/null
+++ b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec
@@ -0,0 +1,150 @@
+# Test for vacuum's reduced processing of heap pages (used for any heap page
+# where a cleanup lock isn't immediately available)
+#
+# Debugging tip: Change VACUUM to VACUUM VERBOSE to get feedback on what's
+# really going on
+
+# Use name type here to avoid TOAST table:
+setup
+{
+ CREATE TABLE smalltbl AS SELECT i AS id, 't'::name AS t FROM generate_series(1,20) i;
+ ALTER TABLE smalltbl SET (autovacuum_enabled = off);
+ ALTER TABLE smalltbl ADD PRIMARY KEY (id);
+}
+setup
+{
+ VACUUM ANALYZE smalltbl;
+}
+
+teardown
+{
+ DROP TABLE smalltbl;
+}
+
+# This session holds a pin on smalltbl's only heap page:
+session pinholder
+step pinholder_cursor
+{
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+}
+step pinholder_commit
+{
+ COMMIT;
+}
+
+# This session inserts and deletes tuples, potentially affecting reltuples:
+session dml
+step dml_insert
+{
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+}
+step dml_delete
+{
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+}
+step dml_begin { BEGIN; }
+step dml_key_share { SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; }
+step dml_commit { COMMIT; }
+
+# Needed for Multixact test:
+session dml_other
+step dml_other_begin { BEGIN; }
+step dml_other_key_share { SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; }
+step dml_other_update { UPDATE smalltbl SET t = 'u' WHERE id = 3; }
+step dml_other_commit { COMMIT; }
+
+# This session runs non-aggressive VACUUM, but with maximally aggressive
+# cutoffs for tuple freezing (e.g., FreezeLimit == OldestXmin):
+session vacuumer
+setup
+{
+ SET vacuum_freeze_min_age = 0;
+ SET vacuum_multixact_freeze_min_age = 0;
+}
+step vacuumer_nonaggressive_vacuum
+{
+ VACUUM smalltbl;
+}
+step vacuumer_pg_class_stats
+{
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+}
+
+# Test VACUUM's reltuples counting mechanism.
+#
+# Final pg_class.reltuples should never be affected by VACUUM's inability to
+# get a cleanup lock on any page, except to the extent that any cleanup lock
+# contention changes the number of tuples that remain ("missed dead" tuples
+# are counted in reltuples, much like "recently dead" tuples).
+
+# Easy case:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ vacuumer_pg_class_stats # End with 21 tuples
+
+# Harder case -- count 21 tuples at the end (like last time), but with cleanup
+# lock contention this time:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ pinholder_cursor
+ vacuumer_nonaggressive_vacuum
+ vacuumer_pg_class_stats # End with 21 tuples
+ pinholder_commit # order doesn't matter
+
+# Same as "harder case", but vary the order, and delete an inserted row:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ pinholder_cursor
+ dml_insert
+ dml_delete
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ # reltuples is 21 here again -- "recently dead" tuple won't be included in
+ # count here:
+ vacuumer_pg_class_stats
+ pinholder_commit # order doesn't matter
+
+# Same as "harder case", but initial insert and delete before cursor:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ dml_delete
+ pinholder_cursor
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ # reltuples is 21 here again -- "missed dead" tuple ("recently dead" when
+ # concurrent activity held back VACUUM's OldestXmin) won't be included in
+ # count here:
+ vacuumer_pg_class_stats
+ pinholder_commit # order doesn't matter
+
+# Test VACUUM's mechanism for skipping MultiXact freezing.
+#
+# This provides test coverage for code paths that are only hit when we need to
+# freeze, but inability to acquire a cleanup lock on a heap page makes
+# freezing some XIDs/XMIDs < FreezeLimit/MultiXactCutoff impossible (without
+# waiting for a cleanup lock, which non-aggressive VACUUM is unwilling to do).
+permutation
+ dml_begin
+ dml_other_begin
+ dml_key_share
+ dml_other_key_share
+ # Will get cleanup lock, can't advance relminmxid yet:
+ # (though will usually advance relfrozenxid by ~2 XIDs)
+ vacuumer_nonaggressive_vacuum
+ pinholder_cursor
+ dml_other_update
+ dml_commit
+ dml_other_commit
+ # Can't cleanup lock, so still can't advance relminmxid here:
+ # (relfrozenxid held back by XIDs in MultiXact too)
+ vacuumer_nonaggressive_vacuum
+ pinholder_commit
+ # Pin was dropped, so will advance relminmxid, at long last:
+ # (ditto for relfrozenxid advancement)
+ vacuumer_nonaggressive_vacuum
diff --git a/src/test/isolation/specs/vacuum-reltuples.spec b/src/test/isolation/specs/vacuum-reltuples.spec
deleted file mode 100644
index a2a461f2f..000000000
--- a/src/test/isolation/specs/vacuum-reltuples.spec
+++ /dev/null
@@ -1,49 +0,0 @@
-# Test for vacuum's handling of reltuples when pages are skipped due
-# to page pins. We absolutely need to avoid setting reltuples=0 in
-# such cases, since that interferes badly with planning.
-#
-# Expected result for all three permutation is 21 tuples, including
-# the second permutation. VACUUM is able to count the concurrently
-# inserted tuple in its final reltuples, even when a cleanup lock
-# cannot be acquired on the affected heap page.
-
-setup {
- create table smalltbl
- as select i as id from generate_series(1,20) i;
- alter table smalltbl set (autovacuum_enabled = off);
-}
-setup {
- vacuum analyze smalltbl;
-}
-
-teardown {
- drop table smalltbl;
-}
-
-session worker
-step open {
- begin;
- declare c1 cursor for select 1 as dummy from smalltbl;
-}
-step fetch1 {
- fetch next from c1;
-}
-step close {
- commit;
-}
-step stats {
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-}
-
-session vacuumer
-step vac {
- vacuum smalltbl;
-}
-step modify {
- insert into smalltbl select max(id)+1 from smalltbl;
-}
-
-permutation modify vac stats
-permutation modify open fetch1 vac close stats
-permutation modify vac stats
--
2.32.0
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-30 06:10 Justin Pryzby <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Justin Pryzby @ 2022-03-30 06:10 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; [email protected]
+ diff = (int32) (vacrel->NewRelfrozenXid - vacrel->relfrozenxid);
+ Assert(diff > 0);
Did you see that this crashed on windows cfbot?
https://api.cirrus-ci.com/v1/artifact/task/4592929254670336/log/tmp_check/postmaster.log
TRAP: FailedAssertion("diff > 0", File: "c:\cirrus\src\backend\access\heap\vacuumlazy.c", Line: 724, PID: 5984)
abort() has been called2022-03-30 03:48:30.267 GMT [5316][client backend] [pg_regress/tablefunc][3/15389:0] ERROR: infinite recursion detected
2022-03-30 03:48:38.031 GMT [5592][postmaster] LOG: server process (PID 5984) was terminated by exception 0xC0000354
2022-03-30 03:48:38.031 GMT [5592][postmaster] DETAIL: Failed process was running: autovacuum: VACUUM ANALYZE pg_catalog.pg_database
2022-03-30 03:48:38.031 GMT [5592][postmaster] HINT: See C include file "ntstatus.h" for a description of the hexadecimal value.
https://cirrus-ci.com/task/4592929254670336
00000000`007ff130 00000001`400b4ef8 postgres!ExceptionalCondition(
char * conditionName = 0x00000001`40a915d8 "diff > 0",
char * errorType = 0x00000001`40a915c8 "FailedAssertion",
char * fileName = 0x00000001`40a91598 "c:\cirrus\src\backend\access\heap\vacuumlazy.c",
int lineNumber = 0n724)+0x8d [c:\cirrus\src\backend\utils\error\assert.c @ 70]
00000000`007ff170 00000001`402a0914 postgres!heap_vacuum_rel(
struct RelationData * rel = 0x00000000`00a51088,
struct VacuumParams * params = 0x00000000`00a8420c,
struct BufferAccessStrategyData * bstrategy = 0x00000000`00a842a0)+0x1038 [c:\cirrus\src\backend\access\heap\vacuumlazy.c @ 724]
00000000`007ff350 00000001`402a4686 postgres!table_relation_vacuum(
struct RelationData * rel = 0x00000000`00a51088,
struct VacuumParams * params = 0x00000000`00a8420c,
struct BufferAccessStrategyData * bstrategy = 0x00000000`00a842a0)+0x34 [c:\cirrus\src\include\access\tableam.h @ 1681]
00000000`007ff380 00000001`402a1a2d postgres!vacuum_rel(
unsigned int relid = 0x4ee,
struct RangeVar * relation = 0x00000000`01799ae0,
struct VacuumParams * params = 0x00000000`00a8420c)+0x5a6 [c:\cirrus\src\backend\commands\vacuum.c @ 2068]
00000000`007ff400 00000001`4050f1ef postgres!vacuum(
struct List * relations = 0x00000000`0179df58,
struct VacuumParams * params = 0x00000000`00a8420c,
struct BufferAccessStrategyData * bstrategy = 0x00000000`00a842a0,
bool isTopLevel = true)+0x69d [c:\cirrus\src\backend\commands\vacuum.c @ 482]
00000000`007ff5f0 00000001`4050dc95 postgres!autovacuum_do_vac_analyze(
struct autovac_table * tab = 0x00000000`00a84208,
struct BufferAccessStrategyData * bstrategy = 0x00000000`00a842a0)+0x8f [c:\cirrus\src\backend\postmaster\autovacuum.c @ 3248]
00000000`007ff640 00000001`4050b4e3 postgres!do_autovacuum(void)+0xef5 [c:\cirrus\src\backend\postmaster\autovacuum.c @ 2503]
It seems like there should be even more logs, especially since it says:
[03:48:43.119] Uploading 3 artifacts for c:\cirrus\**\*.diffs
[03:48:43.122] Uploaded c:\cirrus\contrib\tsm_system_rows\regression.diffs
[03:48:43.125] Uploaded c:\cirrus\contrib\tsm_system_time\regression.diffs
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-30 07:01 Peter Geoghegan <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-30 07:01 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Tue, Mar 29, 2022 at 11:10 PM Justin Pryzby <[email protected]> wrote:
>
> + diff = (int32) (vacrel->NewRelfrozenXid - vacrel->relfrozenxid);
> + Assert(diff > 0);
>
> Did you see that this crashed on windows cfbot?
>
> https://api.cirrus-ci.com/v1/artifact/task/4592929254670336/log/tmp_check/postmaster.log
> TRAP: FailedAssertion("diff > 0", File: "c:\cirrus\src\backend\access\heap\vacuumlazy.c", Line: 724, PID: 5984)
That's weird. There are very similar assertions a little earlier, that
must have *not* failed here, before the call to vac_update_relstats().
I was actually thinking of removing this assertion for that reason --
I thought that it was redundant.
Perhaps something is amiss inside vac_update_relstats(), where the
boolean flag that indicates that pg_class.relfrozenxid was advanced is
set:
if (frozenxid_updated)
*frozenxid_updated = false;
if (TransactionIdIsNormal(frozenxid) &&
pgcform->relfrozenxid != frozenxid &&
(TransactionIdPrecedes(pgcform->relfrozenxid, frozenxid) ||
TransactionIdPrecedes(ReadNextTransactionId(),
pgcform->relfrozenxid)))
{
if (frozenxid_updated)
*frozenxid_updated = true;
pgcform->relfrozenxid = frozenxid;
dirty = true;
}
Maybe the "existing relfrozenxid is in the future, silently update
relfrozenxid" part of the condition (which involves
ReadNextTransactionId()) somehow does the wrong thing here. But how?
The other assertions take into account the fact that OldestXmin can
itself "go backwards" across VACUUM operations against the same table:
Assert(!aggressive || vacrel->NewRelfrozenXid == OldestXmin ||
TransactionIdPrecedesOrEquals(FreezeLimit,
vacrel->NewRelfrozenXid));
Note the "vacrel->NewRelfrozenXid == OldestXmin", without which the
assertion will fail pretty easily when the regression tests are run.
Perhaps I need to do something like that with the other assertion as
well (or more likely just get rid of it). Will figure it out tomorrow.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 00:50 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 00:50 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Andres Freund <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 30, 2022 at 12:01 AM Peter Geoghegan <[email protected]> wrote:
> Perhaps something is amiss inside vac_update_relstats(), where the
> boolean flag that indicates that pg_class.relfrozenxid was advanced is
> set:
>
> if (frozenxid_updated)
> *frozenxid_updated = false;
> if (TransactionIdIsNormal(frozenxid) &&
> pgcform->relfrozenxid != frozenxid &&
> (TransactionIdPrecedes(pgcform->relfrozenxid, frozenxid) ||
> TransactionIdPrecedes(ReadNextTransactionId(),
> pgcform->relfrozenxid)))
> {
> if (frozenxid_updated)
> *frozenxid_updated = true;
> pgcform->relfrozenxid = frozenxid;
> dirty = true;
> }
>
> Maybe the "existing relfrozenxid is in the future, silently update
> relfrozenxid" part of the condition (which involves
> ReadNextTransactionId()) somehow does the wrong thing here. But how?
I tried several times to recreate this issue on CI. No luck with that,
though -- can't get it to fail again after 4 attempts.
This was a VACUUM of pg_database, run from an autovacuum worker. I am
vaguely reminded of the two bugs fixed by Andres in commit a54e1f15.
Both were issues with the shared relcache init file affecting shared
and nailed catalog relations. Those bugs had symptoms like " ERROR:
found xmin ... from before relfrozenxid ..." for various system
catalogs.
We know that this particular assertion did not fail during the same VACUUM:
Assert(vacrel->NewRelfrozenXid == OldestXmin ||
TransactionIdPrecedesOrEquals(vacrel->relfrozenxid,
vacrel->NewRelfrozenXid));
So it's hard to see how this could be a bug in the patch -- the final
new relfrozenxid is presumably equal to VACUUM's OldestXmin in the
problem scenario seen on the CI Windows instance yesterday (that's why
this earlier assertion didn't fail). The assertion I'm showing here
needs the "vacrel->NewRelfrozenXid == OldestXmin" part of the
condition to account for the fact that
OldestXmin/GetOldestNonRemovableTransactionId() is known to "go
backwards". Without that the regression tests will fail quite easily.
The surprising part of the CI failure must have taken place just after
this assertion, when VACUUM's call to vacuum_set_xid_limits() actually
updates pg_class.relfrozenxid with vacrel->NewRelfrozenXid --
presumably because the existing relfrozenxid appeared to be "in the
future" when we examine it in pg_class again. We see evidence that
this must have happened afterwards, when the closely related assertion
(used only in instrumentation code) fails:
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 02:00 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Andres Freund @ 2022-03-31 02:00 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2022-03-30 17:50:42 -0700, Peter Geoghegan wrote:
> I tried several times to recreate this issue on CI. No luck with that,
> though -- can't get it to fail again after 4 attempts.
It's really annoying that we don't have Assert variants that show the compared
values, that might make it easier to intepret what's going on.
Something vaguely like EXPECT_EQ_U32 in regress.c. Maybe
AssertCmp(type, a, op, b),
Then the assertion could have been something like
AssertCmp(int32, diff, >, 0)
Does the line number in the failed run actually correspond to the xid, rather
than the mxid case? I didn't check.
You could try to increase the likelihood of reproducing the failure by
duplicating the invocation that lead to the crash a few times in the
.cirrus.yml file in your dev branch. That might allow hitting the problem more
quickly.
Maybe reduce autovacuum_naptime in src/tools/ci/pg_ci_base.conf?
Or locally - one thing that windows CI does different from the other platforms
is that it runs isolation, contrib and a bunch of other tests using the same
cluster. Which of course increases the likelihood of autovacuum having stuff
to do, *particularly* on shared relations - normally there's probably not
enough changes for that.
You can do something similar locally on linux with
make -Otarget -C contrib/ -j48 -s USE_MODULE_DB=1 installcheck prove_installcheck=true
(the prove_installcheck=true to prevent tap tests from running, we don't seem
to have another way for that)
I don't think windows uses USE_MODULE_DB=1, but it allows to cause a lot more
load concurrently than running tests serially...
> We know that this particular assertion did not fail during the same VACUUM:
>
> Assert(vacrel->NewRelfrozenXid == OldestXmin ||
> TransactionIdPrecedesOrEquals(vacrel->relfrozenxid,
> vacrel->NewRelfrozenXid));
The comment in your patch says "is either older or newer than FreezeLimit" - I
assume that's some rephrasing damage?
> So it's hard to see how this could be a bug in the patch -- the final
> new relfrozenxid is presumably equal to VACUUM's OldestXmin in the
> problem scenario seen on the CI Windows instance yesterday (that's why
> this earlier assertion didn't fail).
Perhaps it's worth commiting improved assertions on master? If this is indeed
a pre-existing bug, and we're just missing due to slightly less stringent
asserts, we could rectify that separately.
> The surprising part of the CI failure must have taken place just after
> this assertion, when VACUUM's call to vacuum_set_xid_limits() actually
> updates pg_class.relfrozenxid with vacrel->NewRelfrozenXid --
> presumably because the existing relfrozenxid appeared to be "in the
> future" when we examine it in pg_class again. We see evidence that
> this must have happened afterwards, when the closely related assertion
> (used only in instrumentation code) fails:
Hm. This triggers some vague memories. There's some oddities around shared
relations being vacuumed separately in all the databases and thus having
separate horizons.
After "remembering" that, I looked in the cirrus log for the failed run, and
the worker was processing shared a shared relation last:
2022-03-30 03:48:30.238 GMT [5984][autovacuum worker] LOG: automatic analyze of table "contrib_regression.pg_catalog.pg_authid"
Obviously that's not a guarantee that the next table processed also is a
shared catalog, but ...
Oh, the relid is actually in the stack trace. 0x4ee = 1262 =
pg_database. Which makes sense, the test ends up with a high percentage of
dead rows in pg_database, due to all the different contrib tests
creating/dropping a database.
> From my patch:
>
> > if (frozenxid_updated)
> > {
> > - diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
> > + diff = (int32) (vacrel->NewRelfrozenXid - vacrel->relfrozenxid);
> > + Assert(diff > 0);
> > appendStringInfo(&buf,
> > _("new relfrozenxid: %u, which is %d xids ahead of previous value\n"),
> > - FreezeLimit, diff);
> > + vacrel->NewRelfrozenXid, diff);
> > }
Perhaps this ought to be an elog() instead of an Assert()? Something has gone
pear shaped if we get here... It's a bit annoying though, because it'd have to
be a PANIC to be visible on the bf / CI :(.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 02:37 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 2 replies; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 02:37 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 30, 2022 at 7:00 PM Andres Freund <[email protected]> wrote:
> Something vaguely like EXPECT_EQ_U32 in regress.c. Maybe
> AssertCmp(type, a, op, b),
>
> Then the assertion could have been something like
> AssertCmp(int32, diff, >, 0)
I'd definitely use them if they were there.
> Does the line number in the failed run actually correspond to the xid, rather
> than the mxid case? I didn't check.
Yes, I verified -- definitely relfrozenxid.
> You can do something similar locally on linux with
> make -Otarget -C contrib/ -j48 -s USE_MODULE_DB=1 installcheck prove_installcheck=true
> (the prove_installcheck=true to prevent tap tests from running, we don't seem
> to have another way for that)
>
> I don't think windows uses USE_MODULE_DB=1, but it allows to cause a lot more
> load concurrently than running tests serially...
Can't get it to fail locally with that recipe.
> > Assert(vacrel->NewRelfrozenXid == OldestXmin ||
> > TransactionIdPrecedesOrEquals(vacrel->relfrozenxid,
> > vacrel->NewRelfrozenXid));
>
> The comment in your patch says "is either older or newer than FreezeLimit" - I
> assume that's some rephrasing damage?
Both the comment and the assertion are correct. I see what you mean, though.
> Perhaps it's worth commiting improved assertions on master? If this is indeed
> a pre-existing bug, and we're just missing due to slightly less stringent
> asserts, we could rectify that separately.
I don't think there's much chance of the assertion actually hitting
without the rest of the patch series. The new relfrozenxid value is
always going to be OldestXmin - vacuum_min_freeze_age on HEAD, while
with the patch it's sometimes close to OldestXmin. Especially when you
have lots of dead tuples that you churn through constantly (like
pgbench_tellers, or like these system catalogs on the CI test
machine).
> Hm. This triggers some vague memories. There's some oddities around shared
> relations being vacuumed separately in all the databases and thus having
> separate horizons.
That's what I was thinking of, obviously.
> After "remembering" that, I looked in the cirrus log for the failed run, and
> the worker was processing shared a shared relation last:
>
> 2022-03-30 03:48:30.238 GMT [5984][autovacuum worker] LOG: automatic analyze of table "contrib_regression.pg_catalog.pg_authid"
I noticed the same thing myself. Should have said sooner.
> Perhaps this ought to be an elog() instead of an Assert()? Something has gone
> pear shaped if we get here... It's a bit annoying though, because it'd have to
> be a PANIC to be visible on the bf / CI :(.
Yeah, a WARNING would be good here. I can write a new version of my
patch series with a separation patch for that this evening. Actually,
better make it a PANIC for now...
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 02:51 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
1 sibling, 0 replies; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 02:51 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 30, 2022 at 7:37 PM Peter Geoghegan <[email protected]> wrote:
> Yeah, a WARNING would be good here. I can write a new version of my
> patch series with a separation patch for that this evening. Actually,
> better make it a PANIC for now...
Attached is v14, which includes a new patch that PANICs like that in
vac_update_relstats() --- 0003.
This approach also covers manual VACUUMs, which isn't the case with
the failing assertion, which is in instrumentation code (actually
VACUUM VERBOSE might hit it).
I definitely think that something like this should be committed.
Silently ignoring system catalog corruption isn't okay.
--
Peter Geoghegan
Attachments:
[application/octet-stream] v14-0003-PANIC-on-relfrozenxid-from-the-future.patch (3.6K, ../../CAH2-Wz=45r+_UioDrKKWK5=fNFk1BXg41yg_it6h41Sea1NDYQ@mail.gmail.com/2-v14-0003-PANIC-on-relfrozenxid-from-the-future.patch)
download | inline diff:
From 7d2c63423d18f16fd5d4c21e49a4980f78cde69a Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Wed, 30 Mar 2022 18:59:41 -0700
Subject: [PATCH v14 3/4] PANIC on relfrozenxid from the future.
This should be made into a WARNING later on.
---
src/backend/commands/vacuum.c | 78 +++++++++++++++++++++++++++--------
1 file changed, 60 insertions(+), 18 deletions(-)
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index deec4887b..40b6a723b 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -1340,7 +1340,11 @@ vac_update_relstats(Relation relation,
Relation rd;
HeapTuple ctup;
Form_pg_class pgcform;
- bool dirty;
+ bool dirty,
+ relfrozenxid_warn,
+ relminmxid_warn;
+ TransactionId oldrelfrozenxid;
+ MultiXactId oldrelminmxid;
rd = table_open(RelationRelationId, RowExclusiveLock);
@@ -1406,32 +1410,57 @@ vac_update_relstats(Relation relation,
* This should match vac_update_datfrozenxid() concerning what we consider
* to be "in the future".
*/
+ relfrozenxid_warn = false;
if (frozenxid_updated)
*frozenxid_updated = false;
- if (TransactionIdIsNormal(frozenxid) &&
- pgcform->relfrozenxid != frozenxid &&
- (TransactionIdPrecedes(pgcform->relfrozenxid, frozenxid) ||
- TransactionIdPrecedes(ReadNextTransactionId(),
- pgcform->relfrozenxid)))
+ if (TransactionIdIsNormal(frozenxid) && pgcform->relfrozenxid != frozenxid)
{
- if (frozenxid_updated)
- *frozenxid_updated = true;
- pgcform->relfrozenxid = frozenxid;
- dirty = true;
+ bool update = false;
+
+ if (TransactionIdPrecedes(pgcform->relfrozenxid, frozenxid))
+ update = true;
+ else if (TransactionIdPrecedes(ReadNextTransactionId(),
+ pgcform->relfrozenxid))
+ {
+ relfrozenxid_warn = true;
+ oldrelfrozenxid = pgcform->relfrozenxid;
+ update = true;
+ }
+
+ if (update)
+ {
+ if (frozenxid_updated)
+ *frozenxid_updated = true;
+ pgcform->relfrozenxid = frozenxid;
+ dirty = true;
+ }
}
/* Similarly for relminmxid */
+ relminmxid_warn = false;
if (minmulti_updated)
*minmulti_updated = false;
- if (MultiXactIdIsValid(minmulti) &&
- pgcform->relminmxid != minmulti &&
- (MultiXactIdPrecedes(pgcform->relminmxid, minmulti) ||
- MultiXactIdPrecedes(ReadNextMultiXactId(), pgcform->relminmxid)))
+ if (MultiXactIdIsValid(minmulti) && pgcform->relminmxid != minmulti)
{
- if (minmulti_updated)
- *minmulti_updated = true;
- pgcform->relminmxid = minmulti;
- dirty = true;
+ bool update = false;
+
+ if (MultiXactIdPrecedes(pgcform->relminmxid, minmulti))
+ update = true;
+ else if (MultiXactIdPrecedes(ReadNextMultiXactId(),
+ pgcform->relminmxid))
+ {
+ relminmxid_warn = true;
+ oldrelminmxid = pgcform->relminmxid;
+ update = true;
+ }
+
+ if (update)
+ {
+ if (minmulti_updated)
+ *minmulti_updated = true;
+ pgcform->relminmxid = minmulti;
+ dirty = true;
+ }
}
/* If anything changed, write out the tuple. */
@@ -1439,6 +1468,19 @@ vac_update_relstats(Relation relation,
heap_inplace_update(rd, ctup);
table_close(rd, RowExclusiveLock);
+
+ if (relfrozenxid_warn)
+ ereport(PANIC,
+ (errcode(ERRCODE_DATA_CORRUPTED),
+ errmsg_internal("overwrote invalid pg_class.relfrozenxid value %u with new value %u in table \"%s\"",
+ oldrelfrozenxid, frozenxid,
+ RelationGetRelationName(relation))));
+ if (relminmxid_warn)
+ ereport(PANIC,
+ (errcode(ERRCODE_DATA_CORRUPTED),
+ errmsg_internal("overwrote invalid pg_class.relminmxid value %u with new value %u in table \"%s\"",
+ oldrelminmxid, minmulti,
+ RelationGetRelationName(relation))));
}
--
2.32.0
[application/octet-stream] v14-0001-Set-relfrozenxid-to-oldest-extant-XID-seen-by-VA.patch (61.3K, ../../CAH2-Wz=45r+_UioDrKKWK5=fNFk1BXg41yg_it6h41Sea1NDYQ@mail.gmail.com/3-v14-0001-Set-relfrozenxid-to-oldest-extant-XID-seen-by-VA.patch)
download | inline diff:
From 61938823ce68c38aa6f35016a7781d1a4186618d Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v14 1/4] Set relfrozenxid to oldest extant XID seen by VACUUM.
When VACUUM set relfrozenxid before now, it set it to whatever value was
used to determine which tuples to freeze -- the FreezeLimit cutoff.
This approach was very naive: the relfrozenxid invariant only requires
that new relfrozenxid values be <= the oldest extant XID remaining in
the table (at the point that the VACUUM operation ends), which in
general might be much more recent than FreezeLimit.
VACUUM now sets relfrozenxid (and relminmxid) using the exact oldest
extant XID (and oldest extant MultiXactId) from the table, including
XIDs from the table's remaining/unfrozen MultiXacts. This requires that
VACUUM carefully track the oldest unfrozen XID/MultiXactId as it goes.
This optimization doesn't require any changes to the definition of
relfrozenxid, nor does it require changes to the core design of
freezing.
Final relfrozenxid values must still be >= FreezeLimit in an aggressive
VACUUM -- FreezeLimit still acts as a lower bound on the final value
that aggressive VACUUM can set relfrozenxid to. Since standard VACUUMs
still make no guarantees about advancing relfrozenxid, they might as
well set relfrozenxid to a value from well before FreezeLimit when the
opportunity presents itself. In general standard VACUUMs may now set
relfrozenxid to any value > the original relfrozenxid and <= OldestXmin.
Credit for the general idea of using the oldest extant XID to set
pg_class.relfrozenxid at the end of VACUUM goes to Andres Freund.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Andres Freund <[email protected]>
Reviewed-By: Robert Haas <[email protected]>
Discussion: https://postgr.es/m/CAH2-WzkymFbz6D_vL+jmqSn_5q1wsFvFrE+37yLgL_Rkfd6Gzg@mail.gmail.com
---
src/include/access/heapam.h | 6 +-
src/include/access/heapam_xlog.h | 4 +-
src/include/commands/vacuum.h | 1 +
src/backend/access/heap/heapam.c | 332 +++++++++++++-----
src/backend/access/heap/vacuumlazy.c | 180 ++++++----
src/backend/commands/cluster.c | 5 +-
src/backend/commands/vacuum.c | 39 +-
doc/src/sgml/maintenance.sgml | 30 +-
.../expected/vacuum-no-cleanup-lock.out | 189 ++++++++++
.../isolation/expected/vacuum-reltuples.out | 67 ----
src/test/isolation/isolation_schedule | 2 +-
.../specs/vacuum-no-cleanup-lock.spec | 150 ++++++++
.../isolation/specs/vacuum-reltuples.spec | 49 ---
13 files changed, 743 insertions(+), 311 deletions(-)
create mode 100644 src/test/isolation/expected/vacuum-no-cleanup-lock.out
delete mode 100644 src/test/isolation/expected/vacuum-reltuples.out
create mode 100644 src/test/isolation/specs/vacuum-no-cleanup-lock.spec
delete mode 100644 src/test/isolation/specs/vacuum-reltuples.spec
diff --git a/src/include/access/heapam.h b/src/include/access/heapam.h
index b46ab7d73..4403f01e1 100644
--- a/src/include/access/heapam.h
+++ b/src/include/access/heapam.h
@@ -167,8 +167,10 @@ extern void heap_inplace_update(Relation relation, HeapTuple tuple);
extern bool heap_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi);
-extern bool heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi);
+extern bool heap_tuple_would_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
+ MultiXactId cutoff_multi,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out);
extern bool heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple);
extern void simple_heap_insert(Relation relation, HeapTuple tup);
diff --git a/src/include/access/heapam_xlog.h b/src/include/access/heapam_xlog.h
index 5c47fdcec..2d8a7f627 100644
--- a/src/include/access/heapam_xlog.h
+++ b/src/include/access/heapam_xlog.h
@@ -410,7 +410,9 @@ extern bool heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId cutoff_xid,
TransactionId cutoff_multi,
xl_heap_freeze_tuple *frz,
- bool *totally_frozen);
+ bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out);
extern void heap_execute_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple *xlrec_tp);
extern XLogRecPtr log_heap_visible(RelFileNode rnode, Buffer heap_buffer,
diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h
index d64f6268f..ead88edda 100644
--- a/src/include/commands/vacuum.h
+++ b/src/include/commands/vacuum.h
@@ -291,6 +291,7 @@ extern bool vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff);
extern bool vacuum_xid_failsafe_check(TransactionId relfrozenxid,
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 74ad445e5..1ee985f63 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -6079,10 +6079,12 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* Determine what to do during freezing when a tuple is marked by a
* MultiXactId.
*
- * NB -- this might have the side-effect of creating a new MultiXactId!
- *
* "flags" is an output value; it's used to tell caller what to do on return.
- * Possible flags are:
+ *
+ * "mxid_oldest_xid_out" is an output value; it's used to track the oldest
+ * extant Xid within any Multixact that will remain after freezing executes.
+ *
+ * Possible values that we can set in "flags":
* FRM_NOOP
* don't do anything -- keep existing Xmax
* FRM_INVALIDATE_XMAX
@@ -6094,12 +6096,17 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
* FRM_RETURN_IS_MULTI
* The return value is a new MultiXactId to set as new Xmax.
* (caller must obtain proper infomask bits using GetMultiXactIdHintBits)
+ *
+ * "mxid_oldest_xid_out" is only set when "flags" contains either FRM_NOOP or
+ * FRM_RETURN_IS_MULTI, since we only leave behind a MultiXactId for these.
+ *
+ * NB: Creates a _new_ MultiXactId when FRM_RETURN_IS_MULTI is set in "flags".
*/
static TransactionId
FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, MultiXactId cutoff_multi,
- uint16 *flags)
+ uint16 *flags, TransactionId *mxid_oldest_xid_out)
{
TransactionId xid = InvalidTransactionId;
int i;
@@ -6111,6 +6118,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
bool has_lockers;
TransactionId update_xid;
bool update_committed;
+ TransactionId temp_xid_out;
*flags = 0;
@@ -6147,7 +6155,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
if (HEAP_XMAX_IS_LOCKED_ONLY(t_infomask))
{
*flags |= FRM_INVALIDATE_XMAX;
- xid = InvalidTransactionId; /* not strictly necessary */
+ xid = InvalidTransactionId;
}
else
{
@@ -6174,7 +6182,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
(errcode(ERRCODE_DATA_CORRUPTED),
errmsg_internal("cannot freeze committed update xid %u", xid)));
*flags |= FRM_INVALIDATE_XMAX;
- xid = InvalidTransactionId; /* not strictly necessary */
+ xid = InvalidTransactionId;
}
else
{
@@ -6182,6 +6190,10 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
}
}
+ /*
+ * Don't push back mxid_oldest_xid_out using FRM_RETURN_IS_XID Xid, or
+ * when no Xids will remain
+ */
return xid;
}
@@ -6205,6 +6217,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
/* is there anything older than the cutoff? */
need_replace = false;
+ temp_xid_out = *mxid_oldest_xid_out; /* init for FRM_NOOP */
for (i = 0; i < nmembers; i++)
{
if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
@@ -6212,28 +6225,38 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
need_replace = true;
break;
}
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
}
/*
* In the simplest case, there is no member older than the cutoff; we can
- * keep the existing MultiXactId as is.
+ * keep the existing MultiXactId as-is, avoiding a more expensive second
+ * pass over the multi
*/
if (!need_replace)
{
+ /*
+ * When mxid_oldest_xid_out gets pushed back here it's likely that the
+ * update Xid was the oldest member, but we don't rely on that
+ */
*flags |= FRM_NOOP;
+ *mxid_oldest_xid_out = temp_xid_out;
pfree(members);
- return InvalidTransactionId;
+ return multi;
}
/*
- * If the multi needs to be updated, figure out which members do we need
- * to keep.
+ * Do a more thorough second pass over the multi to figure out which
+ * member XIDs actually need to be kept. Checking the precise status of
+ * individual members might even show that we don't need to keep anything.
*/
nnewmembers = 0;
newmembers = palloc(sizeof(MultiXactMember) * nmembers);
has_lockers = false;
update_xid = InvalidTransactionId;
update_committed = false;
+ temp_xid_out = *mxid_oldest_xid_out; /* init for FRM_RETURN_IS_MULTI */
for (i = 0; i < nmembers; i++)
{
@@ -6289,7 +6312,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
}
/*
- * Since the tuple wasn't marked HEAPTUPLE_DEAD by vacuum, the
+ * Since the tuple wasn't totally removed when vacuum pruned, the
* update Xid cannot possibly be older than the xid cutoff. The
* presence of such a tuple would cause corruption, so be paranoid
* and check.
@@ -6302,15 +6325,20 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
update_xid, cutoff_xid)));
/*
- * If we determined that it's an Xid corresponding to an update
- * that must be retained, additionally add it to the list of
- * members of the new Multi, in case we end up using that. (We
- * might still decide to use only an update Xid and not a multi,
- * but it's easier to maintain the list as we walk the old members
- * list.)
+ * We determined that this is an Xid corresponding to an update
+ * that must be retained -- add it to new members list for later.
+ *
+ * Also consider pushing back temp_xid_out, which is needed when
+ * we later conclude that a new multi is required (i.e. when we go
+ * on to set FRM_RETURN_IS_MULTI for our caller because we also
+ * need to retain a locker that's still running).
*/
if (TransactionIdIsValid(update_xid))
+ {
newmembers[nnewmembers++] = members[i];
+ if (TransactionIdPrecedes(members[i].xid, temp_xid_out))
+ temp_xid_out = members[i].xid;
+ }
}
else
{
@@ -6318,8 +6346,18 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
if (TransactionIdIsCurrentTransactionId(members[i].xid) ||
TransactionIdIsInProgress(members[i].xid))
{
- /* running locker cannot possibly be older than the cutoff */
+ /*
+ * Running locker cannot possibly be older than the cutoff.
+ *
+ * The cutoff is <= VACUUM's OldestXmin, which is also the
+ * initial value used for top-level relfrozenxid_out tracking
+ * state. A running locker cannot be older than VACUUM's
+ * OldestXmin, either, so we don't need a temp_xid_out step.
+ */
+ Assert(TransactionIdIsNormal(members[i].xid));
Assert(!TransactionIdPrecedes(members[i].xid, cutoff_xid));
+ Assert(!TransactionIdPrecedes(members[i].xid,
+ *mxid_oldest_xid_out));
newmembers[nnewmembers++] = members[i];
has_lockers = true;
}
@@ -6328,11 +6366,16 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
pfree(members);
+ /*
+ * Determine what to do with caller's multi based on information gathered
+ * during our second pass
+ */
if (nnewmembers == 0)
{
/* nothing worth keeping!? Tell caller to remove the whole thing */
*flags |= FRM_INVALIDATE_XMAX;
xid = InvalidTransactionId;
+ /* Don't push back mxid_oldest_xid_out -- no Xids will remain */
}
else if (TransactionIdIsValid(update_xid) && !has_lockers)
{
@@ -6348,15 +6391,18 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
if (update_committed)
*flags |= FRM_MARK_COMMITTED;
xid = update_xid;
+ /* Don't push back mxid_oldest_xid_out using FRM_RETURN_IS_XID Xid */
}
else
{
/*
* Create a new multixact with the surviving members of the previous
- * one, to set as new Xmax in the tuple.
+ * one, to set as new Xmax in the tuple. The oldest surviving member
+ * might push back mxid_oldest_xid_out.
*/
xid = MultiXactIdCreateFromMembers(nnewmembers, newmembers);
*flags |= FRM_RETURN_IS_MULTI;
+ *mxid_oldest_xid_out = temp_xid_out;
}
pfree(newmembers);
@@ -6375,31 +6421,41 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
* will be totally frozen after these operations are performed and false if
* more freezing will eventually be required.
*
- * Caller is responsible for setting the offset field, if appropriate.
+ * Caller must set frz->offset itself, before heap_execute_freeze_tuple call.
*
* It is assumed that the caller has checked the tuple with
* HeapTupleSatisfiesVacuum() and determined that it is not HEAPTUPLE_DEAD
* (else we should be removing the tuple, not freezing it).
*
- * NB: cutoff_xid *must* be <= the current global xmin, to ensure that any
+ * The *relfrozenxid_out and *relminmxid_out arguments are the current target
+ * relfrozenxid and relminmxid for VACUUM caller's heap rel. Any and all
+ * unfrozen XIDs or MXIDs that remain in caller's rel after VACUUM finishes
+ * _must_ have values >= the final relfrozenxid/relminmxid values in pg_class.
+ * This includes XIDs that remain as MultiXact members from any tuple's xmax.
+ * Each call here pushes back *relfrozenxid_out and/or *relminmxid_out as
+ * needed to avoid unsafe final values in rel's authoritative pg_class tuple.
+ *
+ * NB: cutoff_xid *must* be <= VACUUM's OldestXmin, to ensure that any
* XID older than it could neither be running nor seen as running by any
* open transaction. This ensures that the replacement will not change
* anyone's idea of the tuple state.
- * Similarly, cutoff_multi must be less than or equal to the smallest
- * MultiXactId used by any transaction currently open.
+ * Similarly, cutoff_multi must be <= VACUUM's OldestMxact.
*
- * If the tuple is in a shared buffer, caller must hold an exclusive lock on
- * that buffer.
+ * NB: This function has side effects: it might allocate a new MultiXactId.
+ * It will be set as tuple's new xmax when our *frz output is processed within
+ * heap_execute_freeze_tuple later on. If the tuple is in a shared buffer
+ * then caller had better have an exclusive lock on it already.
*
- * NB: It is not enough to set hint bits to indicate something is
- * committed/invalid -- they might not be set on a standby, or after crash
- * recovery. We really need to remove old xids.
+ * NB: It is not enough to set hint bits to indicate an XID committed/aborted.
+ * The *frz WAL record we output completely removes all old XIDs during REDO.
*/
bool
heap_prepare_freeze_tuple(HeapTupleHeader tuple,
TransactionId relfrozenxid, TransactionId relminmxid,
TransactionId cutoff_xid, TransactionId cutoff_multi,
- xl_heap_freeze_tuple *frz, bool *totally_frozen)
+ xl_heap_freeze_tuple *frz, bool *totally_frozen,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out)
{
bool changed = false;
bool xmax_already_frozen = false;
@@ -6418,7 +6474,9 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* already a permanent value), while in the block below it is set true to
* mean "xmin won't need freezing after what we do to it here" (false
* otherwise). In both cases we're allowed to set totally_frozen, as far
- * as xmin is concerned.
+ * as xmin is concerned. Both cases also don't require relfrozenxid_out
+ * handling, since either way the tuple's xmin will be a permanent value
+ * once we're done with it.
*/
xid = HeapTupleHeaderGetXmin(tuple);
if (!TransactionIdIsNormal(xid))
@@ -6443,6 +6501,12 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
frz->t_infomask |= HEAP_XMIN_FROZEN;
changed = true;
}
+ else
+ {
+ /* xmin to remain unfrozen. Could push back relfrozenxid_out. */
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ }
}
/*
@@ -6452,7 +6516,7 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* freezing, too. Also, if a multi needs freezing, we cannot simply take
* it out --- if there's a live updater Xid, it needs to be kept.
*
- * Make sure to keep heap_tuple_needs_freeze in sync with this.
+ * Make sure to keep heap_tuple_would_freeze in sync with this.
*/
xid = HeapTupleHeaderGetRawXmax(tuple);
@@ -6460,15 +6524,28 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
{
TransactionId newxmax;
uint16 flags;
+ TransactionId mxid_oldest_xid_out = *relfrozenxid_out;
newxmax = FreezeMultiXactId(xid, tuple->t_infomask,
relfrozenxid, relminmxid,
- cutoff_xid, cutoff_multi, &flags);
+ cutoff_xid, cutoff_multi,
+ &flags, &mxid_oldest_xid_out);
freeze_xmax = (flags & FRM_INVALIDATE_XMAX);
if (flags & FRM_RETURN_IS_XID)
{
+ /*
+ * xmax will become an updater Xid (original MultiXact's updater
+ * member Xid will be carried forward as a simple Xid in Xmax).
+ * Might have to ratchet back relfrozenxid_out here, though never
+ * relminmxid_out.
+ */
+ Assert(!freeze_xmax);
+ Assert(TransactionIdIsValid(newxmax));
+ if (TransactionIdPrecedes(newxmax, *relfrozenxid_out))
+ *relfrozenxid_out = newxmax;
+
/*
* NB -- some of these transformations are only valid because we
* know the return Xid is a tuple updater (i.e. not merely a
@@ -6487,6 +6564,19 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
uint16 newbits;
uint16 newbits2;
+ /*
+ * xmax is an old MultiXactId that we have to replace with a new
+ * MultiXactId, to carry forward two or more original member XIDs.
+ * Might have to ratchet back relfrozenxid_out here, though never
+ * relminmxid_out.
+ */
+ Assert(!freeze_xmax);
+ Assert(MultiXactIdIsValid(newxmax));
+ Assert(!MultiXactIdPrecedes(newxmax, *relminmxid_out));
+ Assert(TransactionIdPrecedesOrEquals(mxid_oldest_xid_out,
+ *relfrozenxid_out));
+ *relfrozenxid_out = mxid_oldest_xid_out;
+
/*
* We can't use GetMultiXactIdHintBits directly on the new multi
* here; that routine initializes the masks to all zeroes, which
@@ -6503,6 +6593,30 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
changed = true;
}
+ else if (flags & FRM_NOOP)
+ {
+ /*
+ * xmax is a MultiXactId, and nothing about it changes for now.
+ * Might have to ratchet back relminmxid_out, relfrozenxid_out, or
+ * both together.
+ */
+ Assert(!freeze_xmax);
+ Assert(MultiXactIdIsValid(newxmax) && xid == newxmax);
+ Assert(TransactionIdPrecedesOrEquals(mxid_oldest_xid_out,
+ *relfrozenxid_out));
+ if (MultiXactIdPrecedes(xid, *relminmxid_out))
+ *relminmxid_out = xid;
+ *relfrozenxid_out = mxid_oldest_xid_out;
+ }
+ else
+ {
+ /*
+ * Keeping nothing (neither an Xid nor a MultiXactId) in xmax.
+ * Won't have to ratchet back relminmxid_out or relfrozenxid_out.
+ */
+ Assert(freeze_xmax);
+ Assert(!TransactionIdIsValid(newxmax));
+ }
}
else if (TransactionIdIsNormal(xid))
{
@@ -6527,15 +6641,21 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
errmsg_internal("cannot freeze committed xmax %u",
xid)));
freeze_xmax = true;
+ /* No need for relfrozenxid_out handling, since we'll freeze xmax */
}
else
+ {
freeze_xmax = false;
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ }
}
else if ((tuple->t_infomask & HEAP_XMAX_INVALID) ||
!TransactionIdIsValid(HeapTupleHeaderGetRawXmax(tuple)))
{
freeze_xmax = false;
xmax_already_frozen = true;
+ /* No need for relfrozenxid_out handling for already-frozen xmax */
}
else
ereport(ERROR,
@@ -6576,6 +6696,8 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
* was removed in PostgreSQL 9.0. Note that if we were to respect
* cutoff_xid here, we'd need to make surely to clear totally_frozen
* when we skipped freezing on that basis.
+ *
+ * No need for relfrozenxid_out handling, since we always freeze xvac.
*/
if (TransactionIdIsNormal(xid))
{
@@ -6653,11 +6775,14 @@ heap_freeze_tuple(HeapTupleHeader tuple,
xl_heap_freeze_tuple frz;
bool do_freeze;
bool tuple_totally_frozen;
+ TransactionId relfrozenxid_out = cutoff_xid;
+ MultiXactId relminmxid_out = cutoff_multi;
do_freeze = heap_prepare_freeze_tuple(tuple,
relfrozenxid, relminmxid,
cutoff_xid, cutoff_multi,
- &frz, &tuple_totally_frozen);
+ &frz, &tuple_totally_frozen,
+ &relfrozenxid_out, &relminmxid_out);
/*
* Note that because this is not a WAL-logged operation, we don't need to
@@ -7036,9 +7161,7 @@ ConditionalMultiXactIdWait(MultiXactId multi, MultiXactStatus status,
* heap_tuple_needs_eventual_freeze
*
* Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
- * will eventually require freezing. Similar to heap_tuple_needs_freeze,
- * but there's no cutoff, since we're trying to figure out whether freezing
- * will ever be needed, not whether it's needed now.
+ * will eventually require freezing (if tuple isn't removed by pruning first).
*/
bool
heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
@@ -7082,87 +7205,106 @@ heap_tuple_needs_eventual_freeze(HeapTupleHeader tuple)
}
/*
- * heap_tuple_needs_freeze
+ * heap_tuple_would_freeze
*
- * Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
- * are older than the specified cutoff XID or MultiXactId. If so, return true.
+ * Return value indicates if heap_prepare_freeze_tuple sibling function would
+ * freeze any of the XID/XMID fields from the tuple, given the same cutoffs.
+ * We must also deal with dead tuples here, since (xmin, xmax, xvac) fields
+ * could be processed by pruning away the whole tuple instead of freezing.
*
- * It doesn't matter whether the tuple is alive or dead, we are checking
- * to see if a tuple needs to be removed or frozen to avoid wraparound.
- *
- * NB: Cannot rely on hint bits here, they might not be set after a crash or
- * on a standby.
+ * The *relfrozenxid_out and *relminmxid_out input/output arguments work just
+ * like the heap_prepare_freeze_tuple arguments that they're based on. We
+ * never freeze here, which makes tracking the oldest extant XID/MXID simple.
*/
bool
-heap_tuple_needs_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
- MultiXactId cutoff_multi)
+heap_tuple_would_freeze(HeapTupleHeader tuple, TransactionId cutoff_xid,
+ MultiXactId cutoff_multi,
+ TransactionId *relfrozenxid_out,
+ MultiXactId *relminmxid_out)
{
TransactionId xid;
+ MultiXactId multi;
+ bool would_freeze = false;
+ /* First deal with xmin */
xid = HeapTupleHeaderGetXmin(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
-
- /*
- * The considerations for multixacts are complicated; look at
- * heap_prepare_freeze_tuple for justifications. This routine had better
- * be in sync with that one!
- */
- if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
+ if (TransactionIdIsNormal(xid))
{
- MultiXactId multi;
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ would_freeze = true;
+ }
+ /* Now deal with xmax */
+ xid = InvalidTransactionId;
+ multi = InvalidMultiXactId;
+ if (tuple->t_infomask & HEAP_XMAX_IS_MULTI)
multi = HeapTupleHeaderGetRawXmax(tuple);
- if (!MultiXactIdIsValid(multi))
- {
- /* no xmax set, ignore */
- ;
- }
- else if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
- return true;
- else if (MultiXactIdPrecedes(multi, cutoff_multi))
- return true;
- else
- {
- MultiXactMember *members;
- int nmembers;
- int i;
+ else
+ xid = HeapTupleHeaderGetRawXmax(tuple);
- /* need to check whether any member of the mxact is too old */
-
- nmembers = GetMultiXactIdMembers(multi, &members, false,
- HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
-
- for (i = 0; i < nmembers; i++)
- {
- if (TransactionIdPrecedes(members[i].xid, cutoff_xid))
- {
- pfree(members);
- return true;
- }
- }
- if (nmembers > 0)
- pfree(members);
- }
+ if (TransactionIdIsNormal(xid))
+ {
+ /* xmax is a non-permanent XID */
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ would_freeze = true;
+ }
+ else if (!MultiXactIdIsValid(multi))
+ {
+ /* xmax is a permanent XID or invalid MultiXactId/XID */
+ }
+ else if (HEAP_LOCKED_UPGRADED(tuple->t_infomask))
+ {
+ /* xmax is a pg_upgrade'd MultiXact, which can't have updater XID */
+ if (MultiXactIdPrecedes(multi, *relminmxid_out))
+ *relminmxid_out = multi;
+ /* heap_prepare_freeze_tuple always freezes pg_upgrade'd xmax */
+ would_freeze = true;
}
else
{
- xid = HeapTupleHeaderGetRawXmax(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ /* xmax is a MultiXactId that may have an updater XID */
+ MultiXactMember *members;
+ int nmembers;
+
+ if (MultiXactIdPrecedes(multi, *relminmxid_out))
+ *relminmxid_out = multi;
+ if (MultiXactIdPrecedes(multi, cutoff_multi))
+ would_freeze = true;
+
+ /* need to check whether any member of the mxact is old */
+ nmembers = GetMultiXactIdMembers(multi, &members, false,
+ HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask));
+
+ for (int i = 0; i < nmembers; i++)
+ {
+ xid = members[i].xid;
+ Assert(TransactionIdIsNormal(xid));
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ if (TransactionIdPrecedes(xid, cutoff_xid))
+ would_freeze = true;
+ }
+ if (nmembers > 0)
+ pfree(members);
}
if (tuple->t_infomask & HEAP_MOVED)
{
xid = HeapTupleHeaderGetXvac(tuple);
- if (TransactionIdIsNormal(xid) &&
- TransactionIdPrecedes(xid, cutoff_xid))
- return true;
+ if (TransactionIdIsNormal(xid))
+ {
+ if (TransactionIdPrecedes(xid, *relfrozenxid_out))
+ *relfrozenxid_out = xid;
+ /* heap_prepare_freeze_tuple always freezes xvac */
+ would_freeze = true;
+ }
}
- return false;
+ return would_freeze;
}
/*
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 87ab7775a..110bbfb56 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -144,7 +144,7 @@ typedef struct LVRelState
Relation *indrels;
int nindexes;
- /* Aggressive VACUUM (scan all unfrozen pages)? */
+ /* Aggressive VACUUM? (must set relfrozenxid >= FreezeLimit) */
bool aggressive;
/* Use visibility map to skip? (disabled by DISABLE_PAGE_SKIPPING) */
bool skipwithvm;
@@ -173,8 +173,9 @@ typedef struct LVRelState
/* VACUUM operation's target cutoffs for freezing XIDs and MultiXactIds */
TransactionId FreezeLimit;
MultiXactId MultiXactCutoff;
- /* Are FreezeLimit/MultiXactCutoff still valid? */
- bool freeze_cutoffs_valid;
+ /* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
/* Error reporting state */
char *relnamespace;
@@ -319,17 +320,17 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
skipwithvm;
bool frozenxid_updated,
minmulti_updated;
- BlockNumber orig_rel_pages;
+ BlockNumber orig_rel_pages,
+ new_rel_pages,
+ new_rel_allvisible;
char **indnames = NULL;
- BlockNumber new_rel_pages;
- BlockNumber new_rel_allvisible;
- double new_live_tuples;
ErrorContextCallback errcallback;
PgStat_Counter startreadtime = 0;
PgStat_Counter startwritetime = 0;
- TransactionId OldestXmin;
- TransactionId FreezeLimit;
- MultiXactId MultiXactCutoff;
+ TransactionId OldestXmin,
+ FreezeLimit;
+ MultiXactId OldestMxact,
+ MultiXactCutoff;
verbose = (params->options & VACOPT_VERBOSE) != 0;
instrument = (verbose || (IsAutoVacuumWorkerProcess() &&
@@ -351,20 +352,17 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/*
* Get OldestXmin cutoff, which is used to determine which deleted tuples
* are considered DEAD, not just RECENTLY_DEAD. Also get related cutoffs
- * used to determine which XIDs/MultiXactIds will be frozen.
- *
- * If this is an aggressive VACUUM, then we're strictly required to freeze
- * any and all XIDs from before FreezeLimit, so that we will be able to
- * safely advance relfrozenxid up to FreezeLimit below (we must be able to
- * advance relminmxid up to MultiXactCutoff, too).
+ * used to determine which XIDs/MultiXactIds will be frozen. If this is
+ * an aggressive VACUUM then lazy_scan_heap cannot leave behind unfrozen
+ * XIDs < FreezeLimit (or unfrozen MXIDs < MultiXactCutoff).
*/
aggressive = vacuum_set_xid_limits(rel,
params->freeze_min_age,
params->freeze_table_age,
params->multixact_freeze_min_age,
params->multixact_freeze_table_age,
- &OldestXmin, &FreezeLimit,
- &MultiXactCutoff);
+ &OldestXmin, &OldestMxact,
+ &FreezeLimit, &MultiXactCutoff);
skipwithvm = true;
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
@@ -511,10 +509,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->vistest = GlobalVisTestFor(rel);
/* FreezeLimit controls XID freezing (always <= OldestXmin) */
vacrel->FreezeLimit = FreezeLimit;
- /* MultiXactCutoff controls MXID freezing */
+ /* MultiXactCutoff controls MXID freezing (always <= OldestMxact) */
vacrel->MultiXactCutoff = MultiXactCutoff;
- /* Track if cutoffs became invalid (possible in !aggressive case only) */
- vacrel->freeze_cutoffs_valid = true;
+ /* Initialize state used to track oldest extant XID/XMID */
+ vacrel->NewRelfrozenXid = OldestXmin;
+ vacrel->NewRelminMxid = OldestMxact;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -548,16 +547,41 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/*
* Prepare to update rel's pg_class entry.
*
- * In principle new_live_tuples could be -1 indicating that we (still)
- * don't know the tuple count. In practice that probably can't happen,
- * since we'd surely have scanned some pages if the table is new and
- * nonempty.
- *
+ * Aggressive VACUUMs must advance relfrozenxid to a value >= FreezeLimit,
+ * and advance relminmxid to a value >= MultiXactCutoff.
+ */
+ Assert(!aggressive || vacrel->NewRelfrozenXid == OldestXmin ||
+ TransactionIdPrecedesOrEquals(FreezeLimit,
+ vacrel->NewRelfrozenXid));
+ Assert(!aggressive || vacrel->NewRelminMxid == OldestMxact ||
+ MultiXactIdPrecedesOrEquals(MultiXactCutoff,
+ vacrel->NewRelminMxid));
+
+ /*
+ * Non-aggressive VACUUMs might advance relfrozenxid to an XID that is
+ * either older or newer than FreezeLimit (same applies to relminmxid and
+ * MultiXactCutoff). But the state that tracks the oldest remaining XID
+ * and MXID cannot be trusted when any all-visible pages were skipped.
+ */
+ Assert(vacrel->NewRelfrozenXid == OldestXmin ||
+ TransactionIdPrecedesOrEquals(vacrel->relfrozenxid,
+ vacrel->NewRelfrozenXid));
+ Assert(vacrel->NewRelminMxid == OldestMxact ||
+ MultiXactIdPrecedesOrEquals(vacrel->relminmxid,
+ vacrel->NewRelminMxid));
+ if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
+ {
+ /* Keep existing relfrozenxid and relminmxid (can't trust trackers) */
+ Assert(!aggressive);
+ vacrel->NewRelfrozenXid = InvalidTransactionId;
+ vacrel->NewRelminMxid = InvalidMultiXactId;
+ }
+
+ /*
* For safety, clamp relallvisible to be not more than what we're setting
- * relpages to.
+ * pg_class.relpages to
*/
new_rel_pages = vacrel->rel_pages; /* After possible rel truncation */
- new_live_tuples = vacrel->new_live_tuples;
visibilitymap_count(rel, &new_rel_allvisible, NULL);
if (new_rel_allvisible > new_rel_pages)
new_rel_allvisible = new_rel_pages;
@@ -565,33 +589,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/*
* Now actually update rel's pg_class entry.
*
- * Aggressive VACUUM must reliably advance relfrozenxid (and relminmxid).
- * We are able to advance relfrozenxid in a non-aggressive VACUUM too,
- * provided we didn't skip any all-visible (not all-frozen) pages using
- * the visibility map, and assuming that we didn't fail to get a cleanup
- * lock that made it unsafe with respect to FreezeLimit (or perhaps our
- * MultiXactCutoff) established for VACUUM operation.
+ * In principle new_live_tuples could be -1 indicating that we (still)
+ * don't know the tuple count. In practice that can't happen, since we
+ * scan every page that isn't skipped using the visibility map.
*/
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages ||
- !vacrel->freeze_cutoffs_valid)
- {
- /* Cannot advance relfrozenxid/relminmxid */
- Assert(!aggressive);
- frozenxid_updated = minmulti_updated = false;
- vac_update_relstats(rel, new_rel_pages, new_live_tuples,
- new_rel_allvisible, vacrel->nindexes > 0,
- InvalidTransactionId, InvalidMultiXactId,
- NULL, NULL, false);
- }
- else
- {
- Assert(vacrel->scanned_pages + vacrel->frozenskipped_pages ==
- orig_rel_pages);
- vac_update_relstats(rel, new_rel_pages, new_live_tuples,
- new_rel_allvisible, vacrel->nindexes > 0,
- FreezeLimit, MultiXactCutoff,
- &frozenxid_updated, &minmulti_updated, false);
- }
+ vac_update_relstats(rel, new_rel_pages, vacrel->new_live_tuples,
+ new_rel_allvisible, vacrel->nindexes > 0,
+ vacrel->NewRelfrozenXid, vacrel->NewRelminMxid,
+ &frozenxid_updated, &minmulti_updated, false);
/*
* Report results to the stats collector, too.
@@ -605,7 +610,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
*/
pgstat_report_vacuum(RelationGetRelid(rel),
rel->rd_rel->relisshared,
- Max(new_live_tuples, 0),
+ Max(vacrel->new_live_tuples, 0),
vacrel->recently_dead_tuples +
vacrel->missed_dead_tuples);
pgstat_progress_end_command();
@@ -674,7 +679,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->num_index_scans);
appendStringInfo(&buf, _("pages: %u removed, %u remain, %u scanned (%.2f%% of total)\n"),
vacrel->removed_pages,
- vacrel->rel_pages,
+ new_rel_pages,
vacrel->scanned_pages,
orig_rel_pages == 0 ? 100.0 :
100.0 * vacrel->scanned_pages / orig_rel_pages);
@@ -694,17 +699,19 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
OldestXmin, diff);
if (frozenxid_updated)
{
- diff = (int32) (FreezeLimit - vacrel->relfrozenxid);
+ diff = (int32) (vacrel->NewRelfrozenXid - vacrel->relfrozenxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relfrozenxid: %u, which is %d xids ahead of previous value\n"),
- FreezeLimit, diff);
+ vacrel->NewRelfrozenXid, diff);
}
if (minmulti_updated)
{
- diff = (int32) (MultiXactCutoff - vacrel->relminmxid);
+ diff = (int32) (vacrel->NewRelminMxid - vacrel->relminmxid);
+ Assert(diff > 0);
appendStringInfo(&buf,
_("new relminmxid: %u, which is %d mxids ahead of previous value\n"),
- MultiXactCutoff, diff);
+ vacrel->NewRelminMxid, diff);
}
if (orig_rel_pages > 0)
{
@@ -1584,6 +1591,8 @@ lazy_scan_prune(LVRelState *vacrel,
recently_dead_tuples;
int nnewlpdead;
int nfrozen;
+ TransactionId NewRelfrozenXid;
+ MultiXactId NewRelminMxid;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
xl_heap_freeze_tuple frozen[MaxHeapTuplesPerPage];
@@ -1593,7 +1602,9 @@ lazy_scan_prune(LVRelState *vacrel,
retry:
- /* Initialize (or reset) page-level counters */
+ /* Initialize (or reset) page-level state */
+ NewRelfrozenXid = vacrel->NewRelfrozenXid;
+ NewRelminMxid = vacrel->NewRelminMxid;
tuples_deleted = 0;
lpdead_items = 0;
live_tuples = 0;
@@ -1800,8 +1811,8 @@ retry:
vacrel->relminmxid,
vacrel->FreezeLimit,
vacrel->MultiXactCutoff,
- &frozen[nfrozen],
- &tuple_totally_frozen))
+ &frozen[nfrozen], &tuple_totally_frozen,
+ &NewRelfrozenXid, &NewRelminMxid))
{
/* Will execute freeze below */
frozen[nfrozen++].offset = offnum;
@@ -1815,13 +1826,16 @@ retry:
prunestate->all_frozen = false;
}
+ vacrel->offnum = InvalidOffsetNumber;
+
/*
* We have now divided every item on the page into either an LP_DEAD item
* that will need to be vacuumed in indexes later, or a LP_NORMAL tuple
* that remains and needs to be considered for freezing now (LP_UNUSED and
* LP_REDIRECT items also remain, but are of no further interest to us).
*/
- vacrel->offnum = InvalidOffsetNumber;
+ vacrel->NewRelfrozenXid = NewRelfrozenXid;
+ vacrel->NewRelminMxid = NewRelminMxid;
/*
* Consider the need to freeze any items with tuple storage from the page
@@ -1971,6 +1985,8 @@ lazy_scan_noprune(LVRelState *vacrel,
recently_dead_tuples,
missed_dead_tuples;
HeapTupleHeader tupleheader;
+ TransactionId NewRelfrozenXid = vacrel->NewRelfrozenXid;
+ MultiXactId NewRelminMxid = vacrel->NewRelminMxid;
OffsetNumber deadoffsets[MaxHeapTuplesPerPage];
Assert(BufferGetBlockNumber(buf) == blkno);
@@ -2015,22 +2031,37 @@ lazy_scan_noprune(LVRelState *vacrel,
*hastup = true; /* page prevents rel truncation */
tupleheader = (HeapTupleHeader) PageGetItem(page, itemid);
- if (heap_tuple_needs_freeze(tupleheader,
+ if (heap_tuple_would_freeze(tupleheader,
vacrel->FreezeLimit,
- vacrel->MultiXactCutoff))
+ vacrel->MultiXactCutoff,
+ &NewRelfrozenXid, &NewRelminMxid))
{
+ /* Tuple with XID < FreezeLimit (or MXID < MultiXactCutoff) */
if (vacrel->aggressive)
{
- /* Going to have to get cleanup lock for lazy_scan_prune */
+ /*
+ * Aggressive VACUUMs must always be able to advance rel's
+ * relfrozenxid to a value >= FreezeLimit (and be able to
+ * advance rel's relminmxid to a value >= MultiXactCutoff).
+ * The ongoing aggressive VACUUM won't be able to do that
+ * unless it can freeze an XID (or XMID) from this tuple now.
+ *
+ * The only safe option is to have caller perform processing
+ * of this page using lazy_scan_prune. Caller might have to
+ * wait a while for a cleanup lock, but it can't be helped.
+ */
vacrel->offnum = InvalidOffsetNumber;
return false;
}
/*
- * Current non-aggressive VACUUM operation definitely won't be
- * able to advance relfrozenxid or relminmxid
+ * Non-aggressive VACUUMs are under no obligation to advance
+ * relfrozenxid (even by one XID). We can be much laxer here.
+ *
+ * Currently we always just accept an older final relfrozenxid
+ * and/or relminmxid value. We never make caller wait or work a
+ * little harder, even when it likely makes sense to do so.
*/
- vacrel->freeze_cutoffs_valid = false;
}
ItemPointerSet(&(tuple.t_self), blkno, offnum);
@@ -2080,9 +2111,14 @@ lazy_scan_noprune(LVRelState *vacrel,
vacrel->offnum = InvalidOffsetNumber;
/*
- * Now save details of the LP_DEAD items from the page in vacrel (though
- * only when VACUUM uses two-pass strategy)
+ * By here we know for sure that caller can put off freezing and pruning
+ * this particular page until the next VACUUM. Remember its details now.
+ * (lazy_scan_prune expects a clean slate, so we have to do this last.)
*/
+ vacrel->NewRelfrozenXid = NewRelfrozenXid;
+ vacrel->NewRelminMxid = NewRelminMxid;
+
+ /* Save any LP_DEAD items found on the page in dead_items array */
if (vacrel->nindexes == 0)
{
/* Using one-pass strategy (since table has no indexes) */
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c
index 02a7e94bf..a7e988298 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/cluster.c
@@ -767,6 +767,7 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
TupleDesc oldTupDesc PG_USED_FOR_ASSERTS_ONLY;
TupleDesc newTupDesc PG_USED_FOR_ASSERTS_ONLY;
TransactionId OldestXmin;
+ MultiXactId oldestMxact;
TransactionId FreezeXid;
MultiXactId MultiXactCutoff;
bool use_sort;
@@ -856,8 +857,8 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose,
* Since we're going to rewrite the whole table anyway, there's no reason
* not to be aggressive about this.
*/
- vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0,
- &OldestXmin, &FreezeXid, &MultiXactCutoff);
+ vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0, &OldestXmin, &oldestMxact,
+ &FreezeXid, &MultiXactCutoff);
/*
* FreezeXid will become the table's new relfrozenxid, and that mustn't go
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 50a4a612e..deec4887b 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -945,14 +945,22 @@ get_all_vacuum_rels(int options)
* The output parameters are:
* - oldestXmin is the Xid below which tuples deleted by any xact (that
* committed) should be considered DEAD, not just RECENTLY_DEAD.
- * - freezeLimit is the Xid below which all Xids are replaced by
- * FrozenTransactionId during vacuum.
- * - multiXactCutoff is the value below which all MultiXactIds are removed
- * from Xmax.
+ * - oldestMxact is the Mxid below which MultiXacts are definitely not
+ * seen as visible by any running transaction.
+ * - freezeLimit is the Xid below which all Xids are definitely replaced by
+ * FrozenTransactionId during aggressive vacuums.
+ * - multiXactCutoff is the value below which all MultiXactIds are definitely
+ * removed from Xmax during aggressive vacuums.
*
* Return value indicates if vacuumlazy.c caller should make its VACUUM
* operation aggressive. An aggressive VACUUM must advance relfrozenxid up to
- * FreezeLimit, and relminmxid up to multiXactCutoff.
+ * FreezeLimit (at a minimum), and relminmxid up to multiXactCutoff (at a
+ * minimum).
+ *
+ * oldestXmin and oldestMxact are the most recent values that can ever be
+ * passed to vac_update_relstats() as frozenxid and minmulti arguments by our
+ * vacuumlazy.c caller later on. These values should be passed when it turns
+ * out that VACUUM will leave no unfrozen XIDs/XMIDs behind in the table.
*/
bool
vacuum_set_xid_limits(Relation rel,
@@ -961,6 +969,7 @@ vacuum_set_xid_limits(Relation rel,
int multixact_freeze_min_age,
int multixact_freeze_table_age,
TransactionId *oldestXmin,
+ MultiXactId *oldestMxact,
TransactionId *freezeLimit,
MultiXactId *multiXactCutoff)
{
@@ -969,7 +978,6 @@ vacuum_set_xid_limits(Relation rel,
int effective_multixact_freeze_max_age;
TransactionId limit;
TransactionId safeLimit;
- MultiXactId oldestMxact;
MultiXactId mxactLimit;
MultiXactId safeMxactLimit;
int freezetable;
@@ -1065,9 +1073,11 @@ vacuum_set_xid_limits(Relation rel,
effective_multixact_freeze_max_age / 2);
Assert(mxid_freezemin >= 0);
+ /* Remember for caller */
+ *oldestMxact = GetOldestMultiXactId();
+
/* compute the cutoff multi, being careful to generate a valid value */
- oldestMxact = GetOldestMultiXactId();
- mxactLimit = oldestMxact - mxid_freezemin;
+ mxactLimit = *oldestMxact - mxid_freezemin;
if (mxactLimit < FirstMultiXactId)
mxactLimit = FirstMultiXactId;
@@ -1082,8 +1092,8 @@ vacuum_set_xid_limits(Relation rel,
(errmsg("oldest multixact is far in the past"),
errhint("Close open transactions with multixacts soon to avoid wraparound problems.")));
/* Use the safe limit, unless an older mxact is still running */
- if (MultiXactIdPrecedes(oldestMxact, safeMxactLimit))
- mxactLimit = oldestMxact;
+ if (MultiXactIdPrecedes(*oldestMxact, safeMxactLimit))
+ mxactLimit = *oldestMxact;
else
mxactLimit = safeMxactLimit;
}
@@ -1390,12 +1400,9 @@ vac_update_relstats(Relation relation,
* Update relfrozenxid, unless caller passed InvalidTransactionId
* indicating it has no new data.
*
- * Ordinarily, we don't let relfrozenxid go backwards: if things are
- * working correctly, the only way the new frozenxid could be older would
- * be if a previous VACUUM was done with a tighter freeze_min_age, in
- * which case we don't want to forget the work it already did. However,
- * if the stored relfrozenxid is "in the future", then it must be corrupt
- * and it seems best to overwrite it with the cutoff we used this time.
+ * Ordinarily, we don't let relfrozenxid go backwards. However, if the
+ * stored relfrozenxid is "in the future" then it seems best to assume
+ * it's corrupt, and overwrite with the oldest remaining XID in the table.
* This should match vac_update_datfrozenxid() concerning what we consider
* to be "in the future".
*/
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 34d72dba7..0a7b38c17 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -585,9 +585,11 @@
statistics in the system tables <structname>pg_class</structname> and
<structname>pg_database</structname>. In particular,
the <structfield>relfrozenxid</structfield> column of a table's
- <structname>pg_class</structname> row contains the freeze cutoff XID that was used
- by the last aggressive <command>VACUUM</command> for that table. All rows
- inserted by transactions with XIDs older than this cutoff XID are
+ <structname>pg_class</structname> row contains the oldest
+ remaining XID at the end of the most recent <command>VACUUM</command>
+ that successfully advanced <structfield>relfrozenxid</structfield>
+ (typically the most recent aggressive VACUUM). All rows inserted
+ by transactions with XIDs older than this cutoff XID are
guaranteed to have been frozen. Similarly,
the <structfield>datfrozenxid</structfield> column of a database's
<structname>pg_database</structname> row is a lower bound on the unfrozen XIDs
@@ -610,6 +612,17 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
cutoff XID to the current transaction's XID.
</para>
+ <tip>
+ <para>
+ <literal>VACUUM VERBOSE</literal> outputs information about
+ <structfield>relfrozenxid</structfield> and/or
+ <structfield>relminmxid</structfield> when either field was
+ advanced. The same details appear in the server log when <xref
+ linkend="guc-log-autovacuum-min-duration"/> reports on vacuuming
+ by autovacuum.
+ </para>
+ </tip>
+
<para>
<command>VACUUM</command> normally only scans pages that have been modified
since the last vacuum, but <structfield>relfrozenxid</structfield> can only be
@@ -624,7 +637,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
set <literal>age(relfrozenxid)</literal> to a value just a little more than the
<varname>vacuum_freeze_min_age</varname> setting
that was used (more by the number of transactions started since the
- <command>VACUUM</command> started). If no <structfield>relfrozenxid</structfield>-advancing
+ <command>VACUUM</command> started). <command>VACUUM</command>
+ will set <structfield>relfrozenxid</structfield> to the oldest XID
+ that remains in the table, so it's possible that the final value
+ will be much more recent than strictly required.
+ If no <structfield>relfrozenxid</structfield>-advancing
<command>VACUUM</command> is issued on the table until
<varname>autovacuum_freeze_max_age</varname> is reached, an autovacuum will soon
be forced for the table.
@@ -711,8 +728,9 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
</para>
<para>
- Aggressive <command>VACUUM</command> scans, regardless of
- what causes them, enable advancing the value for that table.
+ Aggressive <command>VACUUM</command> scans, regardless of what
+ causes them, are <emphasis>guaranteed</emphasis> to be able to
+ advance the table's <structfield>relminmxid</structfield>.
Eventually, as all tables in all databases are scanned and their
oldest multixact values are advanced, on-disk storage for older
multixacts can be removed.
diff --git a/src/test/isolation/expected/vacuum-no-cleanup-lock.out b/src/test/isolation/expected/vacuum-no-cleanup-lock.out
new file mode 100644
index 000000000..f7bc93e8f
--- /dev/null
+++ b/src/test/isolation/expected/vacuum-no-cleanup-lock.out
@@ -0,0 +1,189 @@
+Parsed test spec with 4 sessions
+
+starting permutation: vacuumer_pg_class_stats dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+
+starting permutation: vacuumer_pg_class_stats dml_insert pinholder_cursor vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: vacuumer_pg_class_stats pinholder_cursor dml_insert dml_delete dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step dml_delete:
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: vacuumer_pg_class_stats dml_insert dml_delete pinholder_cursor dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 20
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step dml_delete:
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_insert:
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step vacuumer_pg_class_stats:
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+
+relpages|reltuples
+--------+---------
+ 1| 21
+(1 row)
+
+step pinholder_commit:
+ COMMIT;
+
+
+starting permutation: dml_begin dml_other_begin dml_key_share dml_other_key_share vacuumer_nonaggressive_vacuum pinholder_cursor dml_other_update dml_commit dml_other_commit vacuumer_nonaggressive_vacuum pinholder_commit vacuumer_nonaggressive_vacuum
+step dml_begin: BEGIN;
+step dml_other_begin: BEGIN;
+step dml_key_share: SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE;
+id
+--
+ 3
+(1 row)
+
+step dml_other_key_share: SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE;
+id
+--
+ 3
+(1 row)
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step pinholder_cursor:
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+
+dummy
+-----
+ 1
+(1 row)
+
+step dml_other_update: UPDATE smalltbl SET t = 'u' WHERE id = 3;
+step dml_commit: COMMIT;
+step dml_other_commit: COMMIT;
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
+step pinholder_commit:
+ COMMIT;
+
+step vacuumer_nonaggressive_vacuum:
+ VACUUM smalltbl;
+
diff --git a/src/test/isolation/expected/vacuum-reltuples.out b/src/test/isolation/expected/vacuum-reltuples.out
deleted file mode 100644
index ce55376e7..000000000
--- a/src/test/isolation/expected/vacuum-reltuples.out
+++ /dev/null
@@ -1,67 +0,0 @@
-Parsed test spec with 2 sessions
-
-starting permutation: modify vac stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step vac:
- vacuum smalltbl;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
-
-starting permutation: modify open fetch1 vac close stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step open:
- begin;
- declare c1 cursor for select 1 as dummy from smalltbl;
-
-step fetch1:
- fetch next from c1;
-
-dummy
------
- 1
-(1 row)
-
-step vac:
- vacuum smalltbl;
-
-step close:
- commit;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
-
-starting permutation: modify vac stats
-step modify:
- insert into smalltbl select max(id)+1 from smalltbl;
-
-step vac:
- vacuum smalltbl;
-
-step stats:
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-
-relpages|reltuples
---------+---------
- 1| 21
-(1 row)
-
diff --git a/src/test/isolation/isolation_schedule b/src/test/isolation/isolation_schedule
index 00749a40b..a48caae22 100644
--- a/src/test/isolation/isolation_schedule
+++ b/src/test/isolation/isolation_schedule
@@ -84,7 +84,7 @@ test: alter-table-4
test: create-trigger
test: sequence-ddl
test: async-notify
-test: vacuum-reltuples
+test: vacuum-no-cleanup-lock
test: timeouts
test: vacuum-concurrent-drop
test: vacuum-conflict
diff --git a/src/test/isolation/specs/vacuum-no-cleanup-lock.spec b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec
new file mode 100644
index 000000000..a88be66de
--- /dev/null
+++ b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec
@@ -0,0 +1,150 @@
+# Test for vacuum's reduced processing of heap pages (used for any heap page
+# where a cleanup lock isn't immediately available)
+#
+# Debugging tip: Change VACUUM to VACUUM VERBOSE to get feedback on what's
+# really going on
+
+# Use name type here to avoid TOAST table:
+setup
+{
+ CREATE TABLE smalltbl AS SELECT i AS id, 't'::name AS t FROM generate_series(1,20) i;
+ ALTER TABLE smalltbl SET (autovacuum_enabled = off);
+ ALTER TABLE smalltbl ADD PRIMARY KEY (id);
+}
+setup
+{
+ VACUUM ANALYZE smalltbl;
+}
+
+teardown
+{
+ DROP TABLE smalltbl;
+}
+
+# This session holds a pin on smalltbl's only heap page:
+session pinholder
+step pinholder_cursor
+{
+ BEGIN;
+ DECLARE c1 CURSOR FOR SELECT 1 AS dummy FROM smalltbl;
+ FETCH NEXT FROM c1;
+}
+step pinholder_commit
+{
+ COMMIT;
+}
+
+# This session inserts and deletes tuples, potentially affecting reltuples:
+session dml
+step dml_insert
+{
+ INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl;
+}
+step dml_delete
+{
+ DELETE FROM smalltbl WHERE id = (SELECT min(id) FROM smalltbl);
+}
+step dml_begin { BEGIN; }
+step dml_key_share { SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; }
+step dml_commit { COMMIT; }
+
+# Needed for Multixact test:
+session dml_other
+step dml_other_begin { BEGIN; }
+step dml_other_key_share { SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; }
+step dml_other_update { UPDATE smalltbl SET t = 'u' WHERE id = 3; }
+step dml_other_commit { COMMIT; }
+
+# This session runs non-aggressive VACUUM, but with maximally aggressive
+# cutoffs for tuple freezing (e.g., FreezeLimit == OldestXmin):
+session vacuumer
+setup
+{
+ SET vacuum_freeze_min_age = 0;
+ SET vacuum_multixact_freeze_min_age = 0;
+}
+step vacuumer_nonaggressive_vacuum
+{
+ VACUUM smalltbl;
+}
+step vacuumer_pg_class_stats
+{
+ SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass;
+}
+
+# Test VACUUM's reltuples counting mechanism.
+#
+# Final pg_class.reltuples should never be affected by VACUUM's inability to
+# get a cleanup lock on any page, except to the extent that any cleanup lock
+# contention changes the number of tuples that remain ("missed dead" tuples
+# are counted in reltuples, much like "recently dead" tuples).
+
+# Easy case:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ vacuumer_pg_class_stats # End with 21 tuples
+
+# Harder case -- count 21 tuples at the end (like last time), but with cleanup
+# lock contention this time:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ pinholder_cursor
+ vacuumer_nonaggressive_vacuum
+ vacuumer_pg_class_stats # End with 21 tuples
+ pinholder_commit # order doesn't matter
+
+# Same as "harder case", but vary the order, and delete an inserted row:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ pinholder_cursor
+ dml_insert
+ dml_delete
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ # reltuples is 21 here again -- "recently dead" tuple won't be included in
+ # count here:
+ vacuumer_pg_class_stats
+ pinholder_commit # order doesn't matter
+
+# Same as "harder case", but initial insert and delete before cursor:
+permutation
+ vacuumer_pg_class_stats # Start with 20 tuples
+ dml_insert
+ dml_delete
+ pinholder_cursor
+ dml_insert
+ vacuumer_nonaggressive_vacuum
+ # reltuples is 21 here again -- "missed dead" tuple ("recently dead" when
+ # concurrent activity held back VACUUM's OldestXmin) won't be included in
+ # count here:
+ vacuumer_pg_class_stats
+ pinholder_commit # order doesn't matter
+
+# Test VACUUM's mechanism for skipping MultiXact freezing.
+#
+# This provides test coverage for code paths that are only hit when we need to
+# freeze, but inability to acquire a cleanup lock on a heap page makes
+# freezing some XIDs/XMIDs < FreezeLimit/MultiXactCutoff impossible (without
+# waiting for a cleanup lock, which non-aggressive VACUUM is unwilling to do).
+permutation
+ dml_begin
+ dml_other_begin
+ dml_key_share
+ dml_other_key_share
+ # Will get cleanup lock, can't advance relminmxid yet:
+ # (though will usually advance relfrozenxid by ~2 XIDs)
+ vacuumer_nonaggressive_vacuum
+ pinholder_cursor
+ dml_other_update
+ dml_commit
+ dml_other_commit
+ # Can't cleanup lock, so still can't advance relminmxid here:
+ # (relfrozenxid held back by XIDs in MultiXact too)
+ vacuumer_nonaggressive_vacuum
+ pinholder_commit
+ # Pin was dropped, so will advance relminmxid, at long last:
+ # (ditto for relfrozenxid advancement)
+ vacuumer_nonaggressive_vacuum
diff --git a/src/test/isolation/specs/vacuum-reltuples.spec b/src/test/isolation/specs/vacuum-reltuples.spec
deleted file mode 100644
index a2a461f2f..000000000
--- a/src/test/isolation/specs/vacuum-reltuples.spec
+++ /dev/null
@@ -1,49 +0,0 @@
-# Test for vacuum's handling of reltuples when pages are skipped due
-# to page pins. We absolutely need to avoid setting reltuples=0 in
-# such cases, since that interferes badly with planning.
-#
-# Expected result for all three permutation is 21 tuples, including
-# the second permutation. VACUUM is able to count the concurrently
-# inserted tuple in its final reltuples, even when a cleanup lock
-# cannot be acquired on the affected heap page.
-
-setup {
- create table smalltbl
- as select i as id from generate_series(1,20) i;
- alter table smalltbl set (autovacuum_enabled = off);
-}
-setup {
- vacuum analyze smalltbl;
-}
-
-teardown {
- drop table smalltbl;
-}
-
-session worker
-step open {
- begin;
- declare c1 cursor for select 1 as dummy from smalltbl;
-}
-step fetch1 {
- fetch next from c1;
-}
-step close {
- commit;
-}
-step stats {
- select relpages, reltuples from pg_class
- where oid='smalltbl'::regclass;
-}
-
-session vacuumer
-step vac {
- vacuum smalltbl;
-}
-step modify {
- insert into smalltbl select max(id)+1 from smalltbl;
-}
-
-permutation modify vac stats
-permutation modify open fetch1 vac close stats
-permutation modify vac stats
--
2.32.0
[application/octet-stream] v14-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch (19.1K, ../../CAH2-Wz=45r+_UioDrKKWK5=fNFk1BXg41yg_it6h41Sea1NDYQ@mail.gmail.com/4-v14-0002-Generalize-how-VACUUM-skips-all-frozen-pages.patch)
download | inline diff:
From 8e6e859dc2ba235b4c41d712e1bdbb4884692725 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 11 Mar 2022 19:16:02 -0800
Subject: [PATCH v14 2/4] Generalize how VACUUM skips all-frozen pages.
Non-aggressive VACUUMs were at a gratuitous disadvantage (relative to
aggressive VACUUMs) around advancing relfrozenxid before now. The
underlying issue was that lazy_scan_heap conditioned its skipping
behavior on whether or not the current VACUUM was aggressive. VACUUM
could fail to increment its frozenskipped_pages counter as a result, and
so could miss out on advancing relfrozenxid (in the non-aggressive case)
for no good reason.
The issue only comes up when concurrent activity might unset a page's
visibility map bit at exactly the wrong time. The non-aggressive case
rechecked the visibility map at the point of skipping each page before
now. This created a window for some other session to concurrently unset
the same heap page's bit in the visibility map. If the bit was unset at
the wrong time, it would cause VACUUM to conservatively conclude that
the page was _never_ all-frozen on recheck. frozenskipped_pages would
not be incremented for the page as a result. lazy_scan_heap had already
committed to skipping the page/range at that point, though -- which made
it unsafe to advance relfrozenxid/relminmxid later on.
Consistently avoid the issue by generalizing how we skip frozen pages
during aggressive VACUUMs: take the same approach when skipping any
skippable page range during aggressive and non-aggressive VACUUMs alike.
The new approach makes ranges (not individual pages) the fundamental
unit of skipping using the visibility map. frozenskipped_pages is
replaced with a boolean flag that represents whether some skippable
range with one or more all-visible pages was actually skipped (making
relfrozenxid unsafe to update).
It is safe for VACUUM to treat a page as all-frozen provided it at least
had its all-frozen bit set after the OldestXmin cutoff was established.
VACUUM is only required to scan pages that might have XIDs < OldestXmin
that are not yet frozen to be able to safely advance relfrozenxid.
Tuples concurrently inserted on skipped pages are equivalent to tuples
concurrently inserted on a block >= rel_pages from the same table.
It's possible that the issue this commit fixes hardly ever came up in
practice. But we only had to be unlucky once to lose out on advancing
relfrozenxid -- a single affected heap page was enough to throw VACUUM
off. That seems like something to avoid on general principle. This is
similar to an issue fixed by commit 44fa8488, which taught vacuumlazy.c
to not give up on non-aggressive relfrozenxid advancement just because a
cleanup lock wasn't immediately available on some heap page.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Robert Haas <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wzn6bGJGfOy3zSTJicKLw99PHJeSOQBOViKjSCinaxUKDQ@mail.gmail.com
Discussion: https://postgr.es/m/CA+TgmobhuzSR442_cfpgxidmiRdL-GdaFSc8SD=GJcpLTx_BAw@mail.gmail.com
---
src/backend/access/heap/vacuumlazy.c | 309 +++++++++++++--------------
1 file changed, 146 insertions(+), 163 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 110bbfb56..b0d70a0b1 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -176,6 +176,7 @@ typedef struct LVRelState
/* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */
TransactionId NewRelfrozenXid;
MultiXactId NewRelminMxid;
+ bool skippedallvis;
/* Error reporting state */
char *relnamespace;
@@ -196,7 +197,6 @@ typedef struct LVRelState
VacDeadItems *dead_items; /* TIDs whose index tuples we'll delete */
BlockNumber rel_pages; /* total number of pages */
BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
- BlockNumber frozenskipped_pages; /* # frozen pages skipped via VM */
BlockNumber removed_pages; /* # pages removed by relation truncation */
BlockNumber lpdead_item_pages; /* # pages with LP_DEAD items */
BlockNumber missed_dead_pages; /* # pages with missed dead tuples */
@@ -247,6 +247,10 @@ typedef struct LVSavedErrInfo
/* non-export function prototypes */
static void lazy_scan_heap(LVRelState *vacrel, int nworkers);
+static BlockNumber lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer,
+ BlockNumber next_block,
+ bool *next_unskippable_allvis,
+ bool *skipping_current_range);
static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf,
BlockNumber blkno, Page page,
bool sharelock, Buffer vmbuffer);
@@ -467,7 +471,6 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize page counters explicitly (be tidy) */
vacrel->scanned_pages = 0;
- vacrel->frozenskipped_pages = 0;
vacrel->removed_pages = 0;
vacrel->lpdead_item_pages = 0;
vacrel->missed_dead_pages = 0;
@@ -514,6 +517,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
/* Initialize state used to track oldest extant XID/XMID */
vacrel->NewRelfrozenXid = OldestXmin;
vacrel->NewRelminMxid = OldestMxact;
+ vacrel->skippedallvis = false;
/*
* Call lazy_scan_heap to perform all required heap pruning, index
@@ -569,7 +573,7 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
Assert(vacrel->NewRelminMxid == OldestMxact ||
MultiXactIdPrecedesOrEquals(vacrel->relminmxid,
vacrel->NewRelminMxid));
- if (vacrel->scanned_pages + vacrel->frozenskipped_pages < orig_rel_pages)
+ if (vacrel->skippedallvis)
{
/* Keep existing relfrozenxid and relminmxid (can't trust trackers) */
Assert(!aggressive);
@@ -838,7 +842,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
next_failsafe_block,
next_fsm_block_to_vacuum;
Buffer vmbuffer = InvalidBuffer;
- bool skipping_blocks;
+ bool next_unskippable_allvis,
+ skipping_current_range;
const int initprog_index[] = {
PROGRESS_VACUUM_PHASE,
PROGRESS_VACUUM_TOTAL_HEAP_BLKS,
@@ -869,179 +874,52 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
initprog_val[2] = dead_items->max_items;
pgstat_progress_update_multi_param(3, initprog_index, initprog_val);
- /*
- * Set things up for skipping blocks using visibility map.
- *
- * Except when vacrel->aggressive is set, we want to skip pages that are
- * all-visible according to the visibility map, but only when we can skip
- * at least SKIP_PAGES_THRESHOLD consecutive pages. Since we're reading
- * sequentially, the OS should be doing readahead for us, so there's no
- * gain in skipping a page now and then; that's likely to disable
- * readahead and so be counterproductive. Also, skipping even a single
- * page means that we can't update relfrozenxid, so we only want to do it
- * if we can skip a goodly number of pages.
- *
- * When vacrel->aggressive is set, we can't skip pages just because they
- * are all-visible, but we can still skip pages that are all-frozen, since
- * such pages do not need freezing and do not affect the value that we can
- * safely set for relfrozenxid or relminmxid.
- *
- * Before entering the main loop, establish the invariant that
- * next_unskippable_block is the next block number >= blkno that we can't
- * skip based on the visibility map, either all-visible for a regular scan
- * or all-frozen for an aggressive scan. We set it to rel_pages when
- * there's no such block. We also set up the skipping_blocks flag
- * correctly at this stage.
- *
- * Note: The value returned by visibilitymap_get_status could be slightly
- * out-of-date, since we make this test before reading the corresponding
- * heap page or locking the buffer. This is OK. If we mistakenly think
- * that the page is all-visible or all-frozen when in fact the flag's just
- * been cleared, we might fail to vacuum the page. It's easy to see that
- * skipping a page when aggressive is not set is not a very big deal; we
- * might leave some dead tuples lying around, but the next vacuum will
- * find them. But even when aggressive *is* set, it's still OK if we miss
- * a page whose all-frozen marking has just been cleared. Any new XIDs
- * just added to that page are necessarily >= vacrel->OldestXmin, and so
- * they'll have no effect on the value to which we can safely set
- * relfrozenxid. A similar argument applies for MXIDs and relminmxid.
- */
- next_unskippable_block = 0;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmstatus;
-
- vmstatus = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmstatus & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmstatus & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
-
- if (next_unskippable_block >= SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
-
+ /* Set up an initial range of skippable blocks using the visibility map */
+ next_unskippable_block = lazy_scan_skip(vacrel, &vmbuffer, 0,
+ &next_unskippable_allvis,
+ &skipping_current_range);
for (blkno = 0; blkno < rel_pages; blkno++)
{
Buffer buf;
Page page;
- bool all_visible_according_to_vm = false;
+ bool all_visible_according_to_vm;
LVPagePruneState prunestate;
- pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
-
- update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
- blkno, InvalidOffsetNumber);
-
if (blkno == next_unskippable_block)
{
- /* Time to advance next_unskippable_block */
- next_unskippable_block++;
- if (vacrel->skipwithvm)
- {
- while (next_unskippable_block < rel_pages)
- {
- uint8 vmskipflags;
-
- vmskipflags = visibilitymap_get_status(vacrel->rel,
- next_unskippable_block,
- &vmbuffer);
- if (vacrel->aggressive)
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_FROZEN) == 0)
- break;
- }
- else
- {
- if ((vmskipflags & VISIBILITYMAP_ALL_VISIBLE) == 0)
- break;
- }
- vacuum_delay_point();
- next_unskippable_block++;
- }
- }
-
/*
- * We know we can't skip the current block. But set up
- * skipping_blocks to do the right thing at the following blocks.
+ * Can't skip this page safely. Must scan the page. But
+ * determine the next skippable range after the page first.
*/
- if (next_unskippable_block - blkno > SKIP_PAGES_THRESHOLD)
- skipping_blocks = true;
- else
- skipping_blocks = false;
+ all_visible_according_to_vm = next_unskippable_allvis;
+ next_unskippable_block = lazy_scan_skip(vacrel, &vmbuffer,
+ blkno + 1,
+ &next_unskippable_allvis,
+ &skipping_current_range);
- /*
- * Normally, the fact that we can't skip this block must mean that
- * it's not all-visible. But in an aggressive vacuum we know only
- * that it's not all-frozen, so it might still be all-visible.
- */
- if (vacrel->aggressive &&
- VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
- all_visible_according_to_vm = true;
+ Assert(next_unskippable_block >= blkno + 1);
}
else
{
- /*
- * The current page can be skipped if we've seen a long enough run
- * of skippable blocks to justify skipping it -- provided it's not
- * the last page in the relation (according to rel_pages).
- *
- * We always scan the table's last page to determine whether it
- * has tuples or not, even if it would otherwise be skipped. This
- * avoids having lazy_truncate_heap() take access-exclusive lock
- * on the table to attempt a truncation that just fails
- * immediately because there are tuples on the last page.
- */
- if (skipping_blocks && blkno < rel_pages - 1)
- {
- /*
- * Tricky, tricky. If this is in aggressive vacuum, the page
- * must have been all-frozen at the time we checked whether it
- * was skippable, but it might not be any more. We must be
- * careful to count it as a skipped all-frozen page in that
- * case, or else we'll think we can't update relfrozenxid and
- * relminmxid. If it's not an aggressive vacuum, we don't
- * know whether it was initially all-frozen, so we have to
- * recheck.
- */
- if (vacrel->aggressive ||
- VM_ALL_FROZEN(vacrel->rel, blkno, &vmbuffer))
- vacrel->frozenskipped_pages++;
- continue;
- }
+ /* Last page always scanned (may need to set nonempty_pages) */
+ Assert(blkno < rel_pages - 1);
- /*
- * SKIP_PAGES_THRESHOLD (threshold for skipping) was not
- * crossed, or this is the last page. Scan the page, even
- * though it's all-visible (and possibly even all-frozen).
- */
+ if (skipping_current_range)
+ continue;
+
+ /* Current range is too small to skip -- just scan the page */
all_visible_according_to_vm = true;
}
- vacuum_delay_point();
-
- /*
- * We're not skipping this page using the visibility map, and so it is
- * (by definition) a scanned page. Any tuples from this page are now
- * guaranteed to be counted below, after some preparatory checks.
- */
vacrel->scanned_pages++;
+ /* Report as block scanned, update error traceback information */
+ pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
+ update_vacuum_error_info(vacrel, NULL, VACUUM_ERRCB_PHASE_SCAN_HEAP,
+ blkno, InvalidOffsetNumber);
+
+ vacuum_delay_point();
+
/*
* Regularly check if wraparound failsafe should trigger.
*
@@ -1241,8 +1119,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
}
/*
- * Handle setting visibility map bit based on what the VM said about
- * the page before pruning started, and using prunestate
+ * Handle setting visibility map bit based on information from the VM
+ * (as of last lazy_scan_skip() call), and from prunestate
*/
if (!all_visible_according_to_vm && prunestate.all_visible)
{
@@ -1274,9 +1152,8 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/*
* As of PostgreSQL 9.2, the visibility map bit should never be set if
* the page-level bit is clear. However, it's possible that the bit
- * got cleared after we checked it and before we took the buffer
- * content lock, so we must recheck before jumping to the conclusion
- * that something bad has happened.
+ * got cleared after lazy_scan_skip() was called, so we must recheck
+ * with buffer lock before concluding that the VM is corrupt.
*/
else if (all_visible_according_to_vm && !PageIsAllVisible(page)
&& VM_ALL_VISIBLE(vacrel->rel, blkno, &vmbuffer))
@@ -1315,7 +1192,7 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
/*
* If the all-visible page is all-frozen but not marked as such yet,
* mark it as all-frozen. Note that all_frozen is only valid if
- * all_visible is true, so we must check both.
+ * all_visible is true, so we must check both prunestate fields.
*/
else if (all_visible_according_to_vm && prunestate.all_visible &&
prunestate.all_frozen &&
@@ -1421,6 +1298,112 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
Assert(!IsInParallelMode());
}
+/*
+ * lazy_scan_skip() -- set up range of skippable blocks using visibility map.
+ *
+ * lazy_scan_heap() calls here every time it needs to set up a new range of
+ * blocks to skip via the visibility map. Caller passes the next block in
+ * line. We return a next_unskippable_block for this range. When there are
+ * no skippable blocks we just return caller's next_block. The all-visible
+ * status of the returned block is set in *next_unskippable_allvis for caller,
+ * too. Block usually won't be all-visible (since it's unskippable), but it
+ * can be during aggressive VACUUMs (as well as in certain edge cases).
+ *
+ * Sets *skipping_current_range to indicate if caller should skip this range.
+ * Costs and benefits drive our decision. Very small ranges won't be skipped.
+ *
+ * Note: our opinion of which blocks can be skipped can go stale immediately.
+ * It's okay if caller "misses" a page whose all-visible or all-frozen marking
+ * was concurrently cleared, though. All that matters is that caller scan all
+ * pages whose tuples might contain XIDs < OldestXmin, or XMIDs < OldestMxact.
+ * (Actually, non-aggressive VACUUMs can choose to skip all-visible pages with
+ * older XIDs/MXIDs. The vacrel->skippedallvis flag will be set here when the
+ * choice to skip such a range is actually made, making everything safe.)
+ */
+static BlockNumber
+lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer, BlockNumber next_block,
+ bool *next_unskippable_allvis, bool *skipping_current_range)
+{
+ BlockNumber rel_pages = vacrel->rel_pages,
+ next_unskippable_block = next_block,
+ nskippable_blocks = 0;
+ bool skipsallvis = false;
+
+ *next_unskippable_allvis = true;
+ while (next_unskippable_block < rel_pages)
+ {
+ uint8 mapbits = visibilitymap_get_status(vacrel->rel,
+ next_unskippable_block,
+ vmbuffer);
+
+ if ((mapbits & VISIBILITYMAP_ALL_VISIBLE) == 0)
+ {
+ Assert((mapbits & VISIBILITYMAP_ALL_FROZEN) == 0);
+ *next_unskippable_allvis = false;
+ break;
+ }
+
+ /*
+ * Caller must scan the last page to determine whether it has tuples
+ * (caller must have the opportunity to set vacrel->nonempty_pages).
+ * This rule avoids having lazy_truncate_heap() take access-exclusive
+ * lock on rel to attempt a truncation that fails anyway, just because
+ * there are tuples on the last page (it is likely that there will be
+ * tuples on other nearby pages as well, but those can be skipped).
+ *
+ * Implement this by always treating the last block as unsafe to skip.
+ */
+ if (next_unskippable_block == rel_pages - 1)
+ break;
+
+ /* DISABLE_PAGE_SKIPPING makes all skipping unsafe */
+ if (!vacrel->skipwithvm)
+ break;
+
+ /*
+ * Aggressive VACUUM caller can't skip pages just because they are
+ * all-visible. They may still skip all-frozen pages, which can't
+ * contain XIDs < OldestXmin (XIDs that aren't already frozen by now).
+ */
+ if ((mapbits & VISIBILITYMAP_ALL_FROZEN) == 0)
+ {
+ if (vacrel->aggressive)
+ break;
+
+ /*
+ * All-visible block is safe to skip in non-aggressive case. But
+ * remember that the final range contains such a block for later.
+ */
+ skipsallvis = true;
+ }
+
+ vacuum_delay_point();
+ next_unskippable_block++;
+ nskippable_blocks++;
+ }
+
+ /*
+ * We only skip a range with at least SKIP_PAGES_THRESHOLD consecutive
+ * pages. Since we're reading sequentially, the OS should be doing
+ * readahead for us, so there's no gain in skipping a page now and then.
+ * Skipping such a range might even discourage sequential detection.
+ *
+ * This test also enables more frequent relfrozenxid advancement during
+ * non-aggressive VACUUMs. If the range has any all-visible pages then
+ * skipping makes updating relfrozenxid unsafe, which is a real downside.
+ */
+ if (nskippable_blocks < SKIP_PAGES_THRESHOLD)
+ *skipping_current_range = false;
+ else
+ {
+ *skipping_current_range = true;
+ if (skipsallvis)
+ vacrel->skippedallvis = true;
+ }
+
+ return next_unskippable_block;
+}
+
/*
* lazy_scan_new_or_empty() -- lazy_scan_heap() new/empty page handling.
*
--
2.32.0
[application/octet-stream] v14-0004-vacuumlazy.c-Move-resource-allocation-to-heap_va.patch (5.1K, ../../CAH2-Wz=45r+_UioDrKKWK5=fNFk1BXg41yg_it6h41Sea1NDYQ@mail.gmail.com/5-v14-0004-vacuumlazy.c-Move-resource-allocation-to-heap_va.patch)
download | inline diff:
From 4cd96ce355a72e9d504c9d88bd1bc3923c08f397 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan <[email protected]>
Date: Fri, 25 Mar 2022 12:51:05 -0700
Subject: [PATCH v14 4/4] vacuumlazy.c: Move resource allocation to
heap_vacuum_rel().
Finish off work started by commit 73f6ec3d: move remaining resource
allocation and deallocation code from lazy_scan_heap() to its caller,
heap_vacuum_rel().
Also remove unnecessary progress report calls for the last block number.
---
src/backend/access/heap/vacuumlazy.c | 74 +++++++++++-----------------
1 file changed, 28 insertions(+), 46 deletions(-)
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index b0d70a0b1..bf82c98fb 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -246,7 +246,7 @@ typedef struct LVSavedErrInfo
/* non-export function prototypes */
-static void lazy_scan_heap(LVRelState *vacrel, int nworkers);
+static void lazy_scan_heap(LVRelState *vacrel);
static BlockNumber lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer,
BlockNumber next_block,
bool *next_unskippable_allvis,
@@ -519,11 +519,28 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
vacrel->NewRelminMxid = OldestMxact;
vacrel->skippedallvis = false;
+ /*
+ * Allocate dead_items array memory using dead_items_alloc. This handles
+ * parallel VACUUM initialization as part of allocating shared memory
+ * space used for dead_items. (But do a failsafe precheck first, to
+ * ensure that parallel VACUUM won't be attempted at all when relfrozenxid
+ * is already dangerously old.)
+ */
+ lazy_check_wraparound_failsafe(vacrel);
+ dead_items_alloc(vacrel, params->nworkers);
+
/*
* Call lazy_scan_heap to perform all required heap pruning, index
* vacuuming, and heap vacuuming (plus related processing)
*/
- lazy_scan_heap(vacrel, params->nworkers);
+ lazy_scan_heap(vacrel);
+
+ /*
+ * Free resources managed by dead_items_alloc. This ends parallel mode in
+ * passing when necessary.
+ */
+ dead_items_cleanup(vacrel);
+ Assert(!IsInParallelMode());
/*
* Update pg_class entries for each of rel's indexes where appropriate.
@@ -833,14 +850,14 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
* supply.
*/
static void
-lazy_scan_heap(LVRelState *vacrel, int nworkers)
+lazy_scan_heap(LVRelState *vacrel)
{
- VacDeadItems *dead_items;
BlockNumber rel_pages = vacrel->rel_pages,
blkno,
next_unskippable_block,
- next_failsafe_block,
- next_fsm_block_to_vacuum;
+ next_failsafe_block = 0,
+ next_fsm_block_to_vacuum = 0;
+ VacDeadItems *dead_items = vacrel->dead_items;
Buffer vmbuffer = InvalidBuffer;
bool next_unskippable_allvis,
skipping_current_range;
@@ -851,23 +868,6 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
};
int64 initprog_val[3];
- /*
- * Do failsafe precheck before calling dead_items_alloc. This ensures
- * that parallel VACUUM won't be attempted when relfrozenxid is already
- * dangerously old.
- */
- lazy_check_wraparound_failsafe(vacrel);
- next_failsafe_block = 0;
-
- /*
- * Allocate the space for dead_items. Note that this handles parallel
- * VACUUM initialization as part of allocating shared memory space used
- * for dead_items.
- */
- dead_items_alloc(vacrel, nworkers);
- dead_items = vacrel->dead_items;
- next_fsm_block_to_vacuum = 0;
-
/* Report that we're scanning the heap, advertising total # of blocks */
initprog_val[0] = PROGRESS_VACUUM_PHASE_SCAN_HEAP;
initprog_val[1] = rel_pages;
@@ -1244,11 +1244,9 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
}
}
- /* report that everything is now scanned */
- pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED, blkno);
-
- /* Clear the block number information */
vacrel->blkno = InvalidBlockNumber;
+ if (BufferIsValid(vmbuffer))
+ ReleaseBuffer(vmbuffer);
/* now we can compute the new value for pg_class.reltuples */
vacrel->new_live_tuples = vac_estimate_reltuples(vacrel->rel, rel_pages,
@@ -1264,15 +1262,9 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
vacrel->missed_dead_tuples;
/*
- * Release any remaining pin on visibility map page.
+ * Do index vacuuming (call each index's ambulkdelete routine), then do
+ * related heap vacuuming
*/
- if (BufferIsValid(vmbuffer))
- {
- ReleaseBuffer(vmbuffer);
- vmbuffer = InvalidBuffer;
- }
-
- /* Perform a final round of index and heap vacuuming */
if (dead_items->num_items > 0)
lazy_vacuum(vacrel);
@@ -1283,19 +1275,9 @@ lazy_scan_heap(LVRelState *vacrel, int nworkers)
if (blkno > next_fsm_block_to_vacuum)
FreeSpaceMapVacuumRange(vacrel->rel, next_fsm_block_to_vacuum, blkno);
- /* report all blocks vacuumed */
- pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_VACUUMED, blkno);
-
- /* Do post-vacuum cleanup */
+ /* Do final index cleanup (call each index's amvacuumcleanup routine) */
if (vacrel->nindexes > 0 && vacrel->do_index_cleanup)
lazy_cleanup_all_indexes(vacrel);
-
- /*
- * Free resources managed by dead_items_alloc. This ends parallel mode in
- * passing when necessary.
- */
- dead_items_cleanup(vacrel);
- Assert(!IsInParallelMode());
}
/*
--
2.32.0
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 03:28 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
1 sibling, 2 replies; 72+ messages in thread
From: Andres Freund @ 2022-03-31 03:28 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
I was able to trigger the crash.
cat ~/tmp/pgbench-createdb.sql
CREATE DATABASE pgb_:client_id;
DROP DATABASE pgb_:client_id;
pgbench -n -P1 -c 10 -j10 -T100 -f ~/tmp/pgbench-createdb.sql
while I was also running
for i in $(seq 1 100); do echo iteration $i; make -Otarget -C contrib/ -s installcheck -j48 -s prove_installcheck=true USE_MODULE_DB=1 > /tmp/ci-$i.log 2>&1; done
I triggered twice now, but it took a while longer the second time.
(gdb) bt full
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
set = {__val = {4194304, 0, 0, 0, 0, 0, 216172782113783808, 2, 2377909399344644096, 18446497967838863616, 0, 0, 0, 0, 0, 0}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007fe49a2db546 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}},
sa_flags = 0, sa_restorer = 0x107e0}
sigs = {__val = {32, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}}
#2 0x00007fe49b9706f1 in ExceptionalCondition (conditionName=0x7fe49ba0618d "diff > 0", errorType=0x7fe49ba05bd1 "FailedAssertion",
fileName=0x7fe49ba05b90 "/home/andres/src/postgresql/src/backend/access/heap/vacuumlazy.c", lineNumber=724)
at /home/andres/src/postgresql/src/backend/utils/error/assert.c:69
No locals.
#3 0x00007fe49b2fc739 in heap_vacuum_rel (rel=0x7fe497a8d148, params=0x7fe49c130d7c, bstrategy=0x7fe49c130e10)
at /home/andres/src/postgresql/src/backend/access/heap/vacuumlazy.c:724
buf = {
data = 0x7fe49c17e238 "automatic vacuum of table \"contrib_regression_dict_int.pg_catalog.pg_database\": index scans: 1\npages: 0 removed, 3 remain, 3 scanned (100.00% of total)\ntuples: 49 removed, 53 remain, 9 are dead but no"..., len = 279, maxlen = 1024, cursor = 0}
msgfmt = 0x7fe49ba06038 "automatic vacuum of table \"%s.%s.%s\": index scans: %d\n"
diff = 0
endtime = 702011687982080
vacrel = 0x7fe49c19b5b8
verbose = false
instrument = true
ru0 = {tv = {tv_sec = 1648696487, tv_usec = 975963}, ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 3086}, {
--Type <RET> for more, q to quit, c to continue without paging--c
ru_maxrss = 10824, __ru_maxrss_word = 10824}, {ru_ixrss = 0, __ru_ixrss_word = 0}, {ru_idrss = 0, __ru_idrss_word = 0}, {ru_isrss = 0, __ru_isrss_word = 0}, {ru_minflt = 449, __ru_minflt_word = 449}, {ru_majflt = 0, __ru_majflt_word = 0}, {ru_nswap = 0, __ru_nswap_word = 0}, {ru_inblock = 0, __ru_inblock_word = 0}, {ru_oublock = 0, __ru_oublock_word = 0}, {ru_msgsnd = 0, __ru_msgsnd_word = 0}, {ru_msgrcv = 0, __ru_msgrcv_word = 0}, {ru_nsignals = 0, __ru_nsignals_word = 0}, {ru_nvcsw = 2, __ru_nvcsw_word = 2}, {ru_nivcsw = 0, __ru_nivcsw_word = 0}}}
starttime = 702011687975964
walusage_start = {wal_records = 0, wal_fpi = 0, wal_bytes = 0}
walusage = {wal_records = 11, wal_fpi = 7, wal_bytes = 30847}
secs = 0
usecs = 6116
read_rate = 16.606033355134073
write_rate = 7.6643230869849575
aggressive = false
skipwithvm = true
frozenxid_updated = true
minmulti_updated = true
orig_rel_pages = 3
new_rel_pages = 3
new_rel_allvisible = 0
indnames = 0x7fe49c19bb28
errcallback = {previous = 0x0, callback = 0x7fe49b3012fd <vacuum_error_callback>, arg = 0x7fe49c19b5b8}
startreadtime = 180
startwritetime = 0
OldestXmin = 67552
FreezeLimit = 4245034848
OldestMxact = 224
MultiXactCutoff = 4289967520
__func__ = "heap_vacuum_rel"
#4 0x00007fe49b523d92 in table_relation_vacuum (rel=0x7fe497a8d148, params=0x7fe49c130d7c, bstrategy=0x7fe49c130e10) at /home/andres/src/postgresql/src/include/access/tableam.h:1680
No locals.
#5 0x00007fe49b527032 in vacuum_rel (relid=1262, relation=0x7fe49c1ae360, params=0x7fe49c130d7c) at /home/andres/src/postgresql/src/backend/commands/vacuum.c:2065
lmode = 4
rel = 0x7fe497a8d148
lockrelid = {relId = 1262, dbId = 0}
toast_relid = 0
save_userid = 10
save_sec_context = 0
save_nestlevel = 2
__func__ = "vacuum_rel"
#6 0x00007fe49b524c3b in vacuum (relations=0x7fe49c1b03a8, params=0x7fe49c130d7c, bstrategy=0x7fe49c130e10, isTopLevel=true) at /home/andres/src/postgresql/src/backend/commands/vacuum.c:482
vrel = 0x7fe49c1ae3b8
cur__state = {l = 0x7fe49c1b03a8, i = 0}
cur = 0x7fe49c1b03c0
_save_exception_stack = 0x7fff97e35a10
_save_context_stack = 0x0
_local_sigjmp_buf = {{__jmpbuf = {140735741652128, 6126579318940970843, 9223372036854775747, 0, 0, 0, 6126579318957748059, 6139499258682879835}, __mask_was_saved = 0, __saved_mask = {__val = {32, 140619848279000, 8590910454, 140619848278592, 32, 140619848278944, 7784, 140619848278592, 140619848278816, 140735741647200, 140619839915137, 8458711686435861857, 32, 4869, 140619848278592, 140619848279024}}}}
_do_rethrow = false
in_vacuum = true
stmttype = 0x7fe49baff1a7 "VACUUM"
in_outer_xact = false
use_own_xacts = true
__func__ = "vacuum"
#7 0x00007fe49b6d483d in autovacuum_do_vac_analyze (tab=0x7fe49c130d78, bstrategy=0x7fe49c130e10) at /home/andres/src/postgresql/src/backend/postmaster/autovacuum.c:3247
rangevar = 0x7fe49c1ae360
rel = 0x7fe49c1ae3b8
rel_list = 0x7fe49c1ae3f0
#8 0x00007fe49b6d34bc in do_autovacuum () at /home/andres/src/postgresql/src/backend/postmaster/autovacuum.c:2495
_save_exception_stack = 0x7fff97e35d70
_save_context_stack = 0x0
_local_sigjmp_buf = {{__jmpbuf = {140735741652128, 6126579318779490139, 9223372036854775747, 0, 0, 0, 6126579319014371163, 6139499700101525339}, __mask_was_saved = 0, __saved_mask = {__val = {140619840139982, 140735741647712, 140619841923928, 957, 140619847223443, 140735741647656, 140619847312112, 140619847223451, 140619847223443, 140619847224399, 0, 139637976727552, 140619817480714, 140735741647616, 140619839856340, 1024}}}}
_do_rethrow = false
tab = 0x7fe49c130d78
skipit = false
stdVacuumCostDelay = 0
stdVacuumCostLimit = 200
iter = {cur = 0x7fe497668da0, end = 0x7fe497668da0}
relid = 1262
classTup = 0x7fe497a6c568
isshared = true
cell__state = {l = 0x7fe49c130d40, i = 0}
classRel = 0x7fe497a5ae18
tuple = 0x0
relScan = 0x7fe49c130928
dbForm = 0x7fe497a64fb8
table_oids = 0x7fe49c130d40
orphan_oids = 0x0
ctl = {num_partitions = 0, ssize = 0, dsize = 1296236544, max_dsize = 140619847224424, keysize = 4, entrysize = 96, hash = 0x0, match = 0x0, keycopy = 0x0, alloc = 0x0, hcxt = 0x7fff97e35c50, hctl = 0x7fe49b9a787e <AllocSetFree+670>}
table_toast_map = 0x7fe49c19d2f0
cell = 0x7fe49c130d58
shared = 0x7fe49c17c360
dbentry = 0x7fe49c18d7a0
bstrategy = 0x7fe49c130e10
key = {sk_flags = 0, sk_attno = 17, sk_strategy = 3, sk_subtype = 0, sk_collation = 950, sk_func = {fn_addr = 0x7fe49b809a6a <chareq>, fn_oid = 61, fn_nargs = 2, fn_strict = true, fn_retset = false, fn_stats = 2 '\002', fn_extra = 0x0, fn_mcxt = 0x7fe49c12f7f0, fn_expr = 0x0}, sk_argument = 116}
pg_class_desc = 0x7fe49c12f910
effective_multixact_freeze_max_age = 400000000
did_vacuum = false
found_concurrent_worker = false
i = 32740
__func__ = "do_autovacuum"
#9 0x00007fe49b6d21c4 in AutoVacWorkerMain (argc=0, argv=0x0) at /home/andres/src/postgresql/src/backend/postmaster/autovacuum.c:1719
dbname = "contrib_regression_dict_int\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
local_sigjmp_buf = {{__jmpbuf = {140735741652128, 6126579318890639195, 9223372036854775747, 0, 0, 0, 6126579318785781595, 6139499699353759579}, __mask_was_saved = 1, __saved_mask = {__val = {18446744066192964099, 8, 140735741648416, 140735741648352, 3156423108750738944, 0, 30, 140735741647888, 140619835812981, 140735741648080, 32666874400, 140735741648448, 140619836964693, 140735741652128, 2586778441, 140735741648448}}}}
dbid = 205328
__func__ = "AutoVacWorkerMain"
#10 0x00007fe49b6d1d5b in StartAutoVacWorker () at /home/andres/src/postgresql/src/backend/postmaster/autovacuum.c:1504
worker_pid = 0
__func__ = "StartAutoVacWorker"
#11 0x00007fe49b6e79af in StartAutovacuumWorker () at /home/andres/src/postgresql/src/backend/postmaster/postmaster.c:5635
bn = 0x7fe49c0da920
__func__ = "StartAutovacuumWorker"
#12 0x00007fe49b6e745d in sigusr1_handler (postgres_signal_arg=10) at /home/andres/src/postgresql/src/backend/postmaster/postmaster.c:5340
save_errno = 4
__func__ = "sigusr1_handler"
#13 <signal handler called>
No locals.
#14 0x00007fe49a3a9fc4 in __GI___select (nfds=8, readfds=0x7fff97e36c20, writefds=0x0, exceptfds=0x0, timeout=0x7fff97e36ca0) at ../sysdeps/unix/sysv/linux/select.c:71
sc_ret = -4
sc_ret = <optimized out>
s = <optimized out>
us = <optimized out>
ns = <optimized out>
ts64 = {tv_sec = 59, tv_nsec = 765565741}
pts64 = <optimized out>
r = <optimized out>
#15 0x00007fe49b6e26c7 in ServerLoop () at /home/andres/src/postgresql/src/backend/postmaster/postmaster.c:1765
timeout = {tv_sec = 60, tv_usec = 0}
rmask = {fds_bits = {224, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}}
selres = -1
now = 1648696487
readmask = {fds_bits = {224, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}}
nSockets = 8
last_lockfile_recheck_time = 1648696432
last_touch_time = 1648696072
__func__ = "ServerLoop"
#16 0x00007fe49b6e2031 in PostmasterMain (argc=55, argv=0x7fe49c0aa2d0) at /home/andres/src/postgresql/src/backend/postmaster/postmaster.c:1473
opt = -1
status = 0
userDoption = 0x7fe49c0951d0 "/srv/dev/pgdev-dev/"
listen_addr_saved = true
i = 64
output_config_variable = 0x0
__func__ = "PostmasterMain"
#17 0x00007fe49b5d2808 in main (argc=55, argv=0x7fe49c0aa2d0) at /home/andres/src/postgresql/src/backend/main/main.c:202
do_check_root = true
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 03:35 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 03:35 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 30, 2022 at 8:28 PM Andres Freund <[email protected]> wrote:
> I triggered twice now, but it took a while longer the second time.
Great.
I wonder if you can get an RR recording...
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 03:35 Andres Freund <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 0 replies; 72+ messages in thread
From: Andres Freund @ 2022-03-31 03:35 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2022-03-30 20:28:44 -0700, Andres Freund wrote:
> I was able to trigger the crash.
>
> cat ~/tmp/pgbench-createdb.sql
> CREATE DATABASE pgb_:client_id;
> DROP DATABASE pgb_:client_id;
>
> pgbench -n -P1 -c 10 -j10 -T100 -f ~/tmp/pgbench-createdb.sql
>
> while I was also running
>
> for i in $(seq 1 100); do echo iteration $i; make -Otarget -C contrib/ -s installcheck -j48 -s prove_installcheck=true USE_MODULE_DB=1 > /tmp/ci-$i.log 2>&1; done
>
> I triggered twice now, but it took a while longer the second time.
Forgot to say how postgres was started. Via my usual devenv script, which
results in:
+ /home/andres/build/postgres/dev-assert/vpath/src/backend/postgres -c hba_file=/home/andres/tmp/pgdev/pg_hba.conf -D /srv/dev/pgdev-dev/ -p 5440 -c shared_buffers=2GB -c wal_level=hot_standby -c max_wal_senders=10 -c track_io_timing=on -c restart_after_crash=false -c max_prepared_transactions=20 -c log_checkpoints=on -c min_wal_size=48MB -c max_wal_size=150GB -c 'cluster_name=dev assert' -c ssl_cert_file=/home/andres/tmp/pgdev/ssl-cert-snakeoil.pem -c ssl_key_file=/home/andres/tmp/pgdev/ssl-cert-snakeoil.key -c 'log_line_prefix=%m [%p][%b][%v:%x][%a] ' -c shared_buffers=16MB -c log_min_messages=debug1 -c log_connections=on -c allow_in_place_tablespaces=1 -c log_autovacuum_min_duration=0 -c log_lock_waits=true -c autovacuum_naptime=10s -c fsync=off
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 04:04 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 2 replies; 72+ messages in thread
From: Andres Freund @ 2022-03-31 04:04 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2022-03-30 20:35:25 -0700, Peter Geoghegan wrote:
> On Wed, Mar 30, 2022 at 8:28 PM Andres Freund <[email protected]> wrote:
> > I triggered twice now, but it took a while longer the second time.
>
> Great.
>
> I wonder if you can get an RR recording...
Started it, but looks like it's too slow.
(gdb) p MyProcPid
$1 = 2172500
(gdb) p vacrel->NewRelfrozenXid
$3 = 717
(gdb) p vacrel->relfrozenxid
$4 = 717
(gdb) p OldestXmin
$5 = 5112
(gdb) p aggressive
$6 = false
There was another autovacuum of pg_database 10s before:
2022-03-30 20:35:17.622 PDT [2165344][autovacuum worker][5/3:0][] LOG: automatic vacuum of table "postgres.pg_catalog.pg_database": index scans: 1
pages: 0 removed, 3 remain, 3 scanned (100.00% of total)
tuples: 61 removed, 4 remain, 1 are dead but not yet removable
removable cutoff: 1921, older by 3 xids when operation ended
new relfrozenxid: 717, which is 3 xids ahead of previous value
index scan needed: 3 pages from table (100.00% of total) had 599 dead item identifiers removed
index "pg_database_datname_index": pages: 2 in total, 0 newly deleted, 0 currently deleted, 0 reusable
index "pg_database_oid_index": pages: 4 in total, 0 newly deleted, 0 currently deleted, 0 reusable
I/O timings: read: 0.029 ms, write: 0.034 ms
avg read rate: 134.120 MB/s, avg write rate: 89.413 MB/s
buffer usage: 35 hits, 12 misses, 8 dirtied
WAL usage: 12 records, 5 full page images, 27218 bytes
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
The dying backend:
2022-03-30 20:35:27.668 PDT [2172500][autovacuum worker][7/0:0][] DEBUG: autovacuum: processing database "contrib_regression_hstore"
...
2022-03-30 20:35:27.690 PDT [2172500][autovacuum worker][7/674:0][] CONTEXT: while cleaning up index "pg_database_oid_index" of relation "pg_catalog.pg_database"
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 04:11 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 04:11 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 30, 2022 at 9:04 PM Andres Freund <[email protected]> wrote:
> (gdb) p vacrel->NewRelfrozenXid
> $3 = 717
> (gdb) p vacrel->relfrozenxid
> $4 = 717
> (gdb) p OldestXmin
> $5 = 5112
> (gdb) p aggressive
> $6 = false
Does this OldestXmin seem reasonable at this point in execution, based
on context? Does it look too high? Something else?
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 04:20 Andres Freund <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 72+ messages in thread
From: Andres Freund @ 2022-03-31 04:20 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2022-03-30 21:04:07 -0700, Andres Freund wrote:
> On 2022-03-30 20:35:25 -0700, Peter Geoghegan wrote:
> > On Wed, Mar 30, 2022 at 8:28 PM Andres Freund <[email protected]> wrote:
> > > I triggered twice now, but it took a while longer the second time.
> >
> > Great.
> >
> > I wonder if you can get an RR recording...
>
> Started it, but looks like it's too slow.
>
> (gdb) p MyProcPid
> $1 = 2172500
>
> (gdb) p vacrel->NewRelfrozenXid
> $3 = 717
> (gdb) p vacrel->relfrozenxid
> $4 = 717
> (gdb) p OldestXmin
> $5 = 5112
> (gdb) p aggressive
> $6 = false
I added a bunch of debug elogs to see what sets *frozenxid_updated to true.
(gdb) p *vacrel
$1 = {rel = 0x7fe24f3e0148, indrels = 0x7fe255c17ef8, nindexes = 2, aggressive = false, skipwithvm = true, failsafe_active = false,
consider_bypass_optimization = true, do_index_vacuuming = true, do_index_cleanup = true, do_rel_truncate = true, bstrategy = 0x7fe255bb0e28, pvs = 0x0,
relfrozenxid = 717, relminmxid = 6, old_live_tuples = 42, OldestXmin = 20751, vistest = 0x7fe255058970 <GlobalVisSharedRels>, FreezeLimit = 4244988047,
MultiXactCutoff = 4289967302, NewRelfrozenXid = 717, NewRelminMxid = 6, skippedallvis = false, relnamespace = 0x7fe255c17bf8 "pg_catalog",
relname = 0x7fe255c17cb8 "pg_database", indname = 0x0, blkno = 4294967295, offnum = 0, phase = VACUUM_ERRCB_PHASE_SCAN_HEAP, verbose = false,
dead_items = 0x7fe255c131d0, rel_pages = 8, scanned_pages = 8, removed_pages = 0, lpdead_item_pages = 0, missed_dead_pages = 0, nonempty_pages = 8,
new_rel_tuples = 124, new_live_tuples = 42, indstats = 0x7fe255c18320, num_index_scans = 0, tuples_deleted = 0, lpdead_items = 0, live_tuples = 42,
recently_dead_tuples = 82, missed_dead_tuples = 0}
But the debug elog reports that
relfrozenxid updated 714 -> 717
relminmxid updated 1 -> 6
Tthe problem is that the crashing backend reads the relfrozenxid/relminmxid
from the shared relcache init file written by another backend:
2022-03-30 21:10:47.626 PDT [2625038][autovacuum worker][6/433:0][] LOG: automatic vacuum of table "contrib_regression_postgres_fdw.pg_catalog.pg_database": index scans: 1
pages: 0 removed, 8 remain, 8 scanned (100.00% of total)
tuples: 4 removed, 114 remain, 72 are dead but not yet removable
removable cutoff: 20751, older by 596 xids when operation ended
new relfrozenxid: 717, which is 3 xids ahead of previous value
new relminmxid: 6, which is 5 mxids ahead of previous value
index scan needed: 3 pages from table (37.50% of total) had 8 dead item identifiers removed
index "pg_database_datname_index": pages: 2 in total, 0 newly deleted, 0 currently deleted, 0 reusable
index "pg_database_oid_index": pages: 6 in total, 0 newly deleted, 2 currently deleted, 2 reusable
I/O timings: read: 0.050 ms, write: 0.102 ms
avg read rate: 209.860 MB/s, avg write rate: 76.313 MB/s
buffer usage: 42 hits, 22 misses, 8 dirtied
WAL usage: 13 records, 5 full page images, 33950 bytes
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
...
2022-03-30 21:10:47.772 PDT [2625043][autovacuum worker][:0][] DEBUG: InitPostgres
2022-03-30 21:10:47.772 PDT [2625043][autovacuum worker][6/0:0][] DEBUG: my backend ID is 6
2022-03-30 21:10:47.772 PDT [2625043][autovacuum worker][6/0:0][] LOG: reading shared init file
2022-03-30 21:10:47.772 PDT [2625043][autovacuum worker][6/443:0][] DEBUG: StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGRESS, xid/sub>
2022-03-30 21:10:47.772 PDT [2625043][autovacuum worker][6/443:0][] LOG: reading non-shared init file
This is basically the inverse of a54e1f15 - we read a *newer* horizon. That's
normally fairly harmless - I think.
Perhaps we should just fetch the horizons from the "local" catalog for shared
rels?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 04:24 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Andres Freund @ 2022-03-31 04:24 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2022-03-30 21:11:48 -0700, Peter Geoghegan wrote:
> On Wed, Mar 30, 2022 at 9:04 PM Andres Freund <[email protected]> wrote:
> > (gdb) p vacrel->NewRelfrozenXid
> > $3 = 717
> > (gdb) p vacrel->relfrozenxid
> > $4 = 717
> > (gdb) p OldestXmin
> > $5 = 5112
> > (gdb) p aggressive
> > $6 = false
>
> Does this OldestXmin seem reasonable at this point in execution, based
> on context? Does it look too high? Something else?
Reasonable:
(gdb) p *ShmemVariableCache
$1 = {nextOid = 78969, oidCount = 2951, nextXid = {value = 21411}, oldestXid = 714, xidVacLimit = 200000714, xidWarnLimit = 2107484361,
xidStopLimit = 2144484361, xidWrapLimit = 2147484361, oldestXidDB = 1, oldestCommitTsXid = 0, newestCommitTsXid = 0, latestCompletedXid = {value = 21408},
xactCompletionCount = 1635, oldestClogXid = 714}
I think the explanation I just sent explains the problem, without "in-memory"
confusion about what's running and what's not.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 04:29 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 2 replies; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 04:29 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 30, 2022 at 9:20 PM Andres Freund <[email protected]> wrote:
> But the debug elog reports that
>
> relfrozenxid updated 714 -> 717
> relminmxid updated 1 -> 6
>
> Tthe problem is that the crashing backend reads the relfrozenxid/relminmxid
> from the shared relcache init file written by another backend:
We should have added logging of relfrozenxid and relminmxid a long time ago.
> This is basically the inverse of a54e1f15 - we read a *newer* horizon. That's
> normally fairly harmless - I think.
Is this one pretty old?
> Perhaps we should just fetch the horizons from the "local" catalog for shared
> rels?
Not sure what you mean.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 04:44 Peter Geoghegan <[email protected]>
parent: Peter Geoghegan <[email protected]>
1 sibling, 0 replies; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 04:44 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 30, 2022 at 9:29 PM Peter Geoghegan <[email protected]> wrote:
> > Perhaps we should just fetch the horizons from the "local" catalog for shared
> > rels?
>
> Not sure what you mean.
Wait, you mean use vacrel->relfrozenxid directly? Seems kind of ugly...
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 04:59 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
1 sibling, 2 replies; 72+ messages in thread
From: Andres Freund @ 2022-03-31 04:59 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2022-03-30 21:29:16 -0700, Peter Geoghegan wrote:
> On Wed, Mar 30, 2022 at 9:20 PM Andres Freund <[email protected]> wrote:
> > But the debug elog reports that
> >
> > relfrozenxid updated 714 -> 717
> > relminmxid updated 1 -> 6
> >
> > Tthe problem is that the crashing backend reads the relfrozenxid/relminmxid
> > from the shared relcache init file written by another backend:
>
> We should have added logging of relfrozenxid and relminmxid a long time ago.
At least at DEBUG1 or such.
> > This is basically the inverse of a54e1f15 - we read a *newer* horizon. That's
> > normally fairly harmless - I think.
>
> Is this one pretty old?
What do you mean with "this one"? The cause for the assert failure?
I'm not sure there's a proper bug on HEAD here. I think at worst it can delay
the horizon increasing a bunch, by falsely not using an aggressive vacuum when
we should have - might even be limited to a single autovacuum cycle.
> > Perhaps we should just fetch the horizons from the "local" catalog for shared
> > rels?
>
> Not sure what you mean.
Basically, instead of relying on the relcache, which for shared relation is
vulnerable to seeing "too new" horizons due to the shared relcache init file,
explicitly load relfrozenxid / relminmxid from the the catalog / syscache.
I.e. fetch the relevant pg_class row in heap_vacuum_rel() (using
SearchSysCache[Copy1](RELID)). And use that to set vacrel->relfrozenxid
etc. Whereas right now we only fetch the pg_class row in
vac_update_relstats(), but use the relcache before.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 16:37 Andres Freund <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 72+ messages in thread
From: Andres Freund @ 2022-03-31 16:37 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2022-03-30 21:59:15 -0700, Andres Freund wrote:
> On 2022-03-30 21:29:16 -0700, Peter Geoghegan wrote:
> > On Wed, Mar 30, 2022 at 9:20 PM Andres Freund <[email protected]> wrote:
> > > Perhaps we should just fetch the horizons from the "local" catalog for shared
> > > rels?
> >
> > Not sure what you mean.
>
> Basically, instead of relying on the relcache, which for shared relation is
> vulnerable to seeing "too new" horizons due to the shared relcache init file,
> explicitly load relfrozenxid / relminmxid from the the catalog / syscache.
>
> I.e. fetch the relevant pg_class row in heap_vacuum_rel() (using
> SearchSysCache[Copy1](RELID)). And use that to set vacrel->relfrozenxid
> etc. Whereas right now we only fetch the pg_class row in
> vac_update_relstats(), but use the relcache before.
Perhaps we should explicitly mask out parts of relcache entries in the shared
init file that we know to be unreliable. I.e. set relfrozenxid, relminmxid to
Invalid* or such.
I even wonder if we should just generally move those out of the fields we have
in the relcache, not just for shared rels loaded from the init
fork. Presumably by just moving them into the CATALOG_VARLEN ifdef.
The only place that appears to access rd_rel->relfrozenxid outside of DDL is
heap_abort_speculative().
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 16:58 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 16:58 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 31, 2022 at 9:37 AM Andres Freund <[email protected]> wrote:
> Perhaps we should explicitly mask out parts of relcache entries in the shared
> init file that we know to be unreliable. I.e. set relfrozenxid, relminmxid to
> Invalid* or such.
That has the advantage of being more honest. If you're going to break
the abstraction, then it seems best to break it in an obvious way,
that leaves no doubts about what you're supposed to be relying on.
This bug doesn't seem like the kind of thing that should be left
as-is. If only because it makes it hard to add something like a
WARNING when we make relfrozenxid go backwards (on the basis of the
existing value apparently being in the future), which we really should
have been doing all along.
The whole reason why we overwrite pg_class.relfrozenxid values from
the future is to ameliorate the effects of more serious bugs like the
pg_upgrade/pg_resetwal one fixed in commit 74cf7d46 not so long ago
(mid last year). We had essentially the same pg_upgrade "from the
future" bug twice (once for relminmxid in the MultiXact bug era,
another more recent version affecting relfrozenxid).
> The only place that appears to access rd_rel->relfrozenxid outside of DDL is
> heap_abort_speculative().
I wonder how necessary that really is. Even if the XID is before
relfrozenxid, does that in itself really make it "in the future"?
Obviously it's often necessary to make the assumption that allowing
wraparound amounts to allowing XIDs "from the future" to exist, which
is dangerous. But why here? Won't pruning by VACUUM eventually correct
the issue anyway?
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 17:11 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Andres Freund @ 2022-03-31 17:11 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2022-03-31 09:58:18 -0700, Peter Geoghegan wrote:
> On Thu, Mar 31, 2022 at 9:37 AM Andres Freund <[email protected]> wrote:
> > The only place that appears to access rd_rel->relfrozenxid outside of DDL is
> > heap_abort_speculative().
>
> I wonder how necessary that really is. Even if the XID is before
> relfrozenxid, does that in itself really make it "in the future"?
> Obviously it's often necessary to make the assumption that allowing
> wraparound amounts to allowing XIDs "from the future" to exist, which
> is dangerous. But why here? Won't pruning by VACUUM eventually correct
> the issue anyway?
I don't think we should weaken defenses against xids from before relfrozenxid
in vacuum / amcheck / .... If anything we should strengthen them.
Isn't it also just plainly required for correctness? We'd not necessarily
trigger a vacuum in time to remove the xid before approaching wraparound if we
put in an xid before relfrozenxid? That happening in prune_xid is obviously
les bad than on actual data, but still.
ISTM we should just use our own xid. Yes, it might delay cleanup a bit
longer. But unless there's already crud on the page (with prune_xid already
set, the abort of the speculative insertion isn't likely to make the
difference?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 17:12 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 17:12 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 30, 2022 at 9:59 PM Andres Freund <[email protected]> wrote:
> I'm not sure there's a proper bug on HEAD here. I think at worst it can delay
> the horizon increasing a bunch, by falsely not using an aggressive vacuum when
> we should have - might even be limited to a single autovacuum cycle.
So, to be clear: vac_update_relstats() never actually considered the
new relfrozenxid value from its vacuumlazy.c caller to be "in the
future"? It just looked that way to the failing assertion in
vacuumlazy.c, because its own version of the original relfrozenxid was
stale from the beginning? And so the worst problem is probably just
that we don't use aggressive VACUUM when we really should in rare
cases?
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 17:16 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 17:16 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 31, 2022 at 10:11 AM Andres Freund <[email protected]> wrote:
> I don't think we should weaken defenses against xids from before relfrozenxid
> in vacuum / amcheck / .... If anything we should strengthen them.
>
> Isn't it also just plainly required for correctness? We'd not necessarily
> trigger a vacuum in time to remove the xid before approaching wraparound if we
> put in an xid before relfrozenxid? That happening in prune_xid is obviously
> les bad than on actual data, but still.
Yeah, you're right. Ambiguity about stuff like this should be avoided
on general principle.
> ISTM we should just use our own xid. Yes, it might delay cleanup a bit
> longer. But unless there's already crud on the page (with prune_xid already
> set, the abort of the speculative insertion isn't likely to make the
> difference?
Speculative insertion abort is pretty rare in the real world, I bet.
The speculative insertion precheck is very likely to work almost
always with real workloads.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 17:50 Andres Freund <[email protected]>
parent: Peter Geoghegan <[email protected]>
0 siblings, 1 reply; 72+ messages in thread
From: Andres Freund @ 2022-03-31 17:50 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2022-03-31 10:12:49 -0700, Peter Geoghegan wrote:
> On Wed, Mar 30, 2022 at 9:59 PM Andres Freund <[email protected]> wrote:
> > I'm not sure there's a proper bug on HEAD here. I think at worst it can delay
> > the horizon increasing a bunch, by falsely not using an aggressive vacuum when
> > we should have - might even be limited to a single autovacuum cycle.
>
> So, to be clear: vac_update_relstats() never actually considered the
> new relfrozenxid value from its vacuumlazy.c caller to be "in the
> future"?
No, I added separate debug messages for those, and also applied your patch,
and it didn't trigger.
I don't immediately see how we could end up computing a frozenxid value that
would be problematic? The pgcform->relfrozenxid value will always be the
"local" value, which afaics can be behind the other database's value (and thus
behind the value from the relcache init file). But it can't be ahead, we have
the proper invalidations for that (I think).
I do think we should apply a version of the warnings you have (with a WARNING
instead of PANIC obviously). I think it's bordering on insanity that we have
so many paths to just silently fix stuff up around vacuum. It's like we want
things to be undebuggable, and to give users no warnings about something being
up.
> It just looked that way to the failing assertion in
> vacuumlazy.c, because its own version of the original relfrozenxid was
> stale from the beginning? And so the worst problem is probably just
> that we don't use aggressive VACUUM when we really should in rare
> cases?
Yes, I think that's right.
Can you repro the issue with my recipe? FWIW, adding log_min_messages=debug5
and fsync=off made the crash trigger more quickly.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 72+ messages in thread
* Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
@ 2022-03-31 18:19 Peter Geoghegan <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Peter Geoghegan @ 2022-03-31 18:19 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Masahiko Sawada <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 31, 2022 at 10:50 AM Andres Freund <[email protected]> wrote:
> > So, to be clear: vac_update_relstats() never actually considered the
> > new relfrozenxid value from its vacuumlazy.c caller to be "in the
> > future"?
>
> No, I added separate debug messages for those, and also applied your patch,
> and it didn't trigger.
The assert is "Assert(diff > 0)", and not "Assert(diff >= 0)". Plus
the other related assert I mentioned did not trigger. So when this
"diff" assert did trigger, the value of "diff" must have been 0 (not a
negative value). While this state does technically indicate that the
"existing" relfrozenxid value (actually a stale version) appears to be
"in the future" (because the OldestXmin XID might still never have
been allocated), it won't ever be in the future according to
vac_update_relstats() (even if it used that version).
I suppose that I might be wrong about that, somehow -- anything is
possible. The important point is that there is currently no evidence
that this bug (or any very recent bug) could ever allow
vac_update_relstats() to actually believe that it needs to update
relfrozenxid/relminmxid, purely because the existing value is in the
future.
The fact that vac_update_relstats() doesn't log/warn when this happens
is very unfortunate, but there is nevertheless no evidence that that
would have informed us of any bug on HEAD, even including the actual
bug here, which is a bug in vacuumlazy.c (not in vac_update_relstats).
> I do think we should apply a version of the warnings you have (with a WARNING
> instead of PANIC obviously). I think it's bordering on insanity that we have
> so many paths to just silently fix stuff up around vacuum. It's like we want
> things to be undebuggable, and to give users no warnings about something being
> up.
Yeah, it's just totally self defeating to not at least log it. I mean
this is a code path that is only hit once per VACUUM, so there is
practically no risk of that causing any new problems.
> Can you repro the issue with my recipe? FWIW, adding log_min_messages=debug5
> and fsync=off made the crash trigger more quickly.
I'll try to do that today. I'm not feeling the most energetic right
now, to be honest.
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH] Introduce an option to make logical replication database specific.
@ 2026-04-03 10:34 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-03 10:34 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch introduces the possibility for a backend to declare that its output
plugin does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in walsender involved in logical replication too, however
that would need thorough analysis of its output plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 ++--
src/backend/access/index/genam.c | 18 ++++++++++++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 ++
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/commands/repack_worker.c | 8 +++++++
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/snapbuild.c | 10 ++++++++-
src/backend/replication/slot.c | 12 +++++++++--
src/backend/storage/ipc/procarray.c | 23 ++++++++++++++++++++-
src/backend/storage/ipc/standby.c | 14 +++++++++++--
src/include/access/genam.h | 8 +++++++
src/include/access/xlog_internal.h | 2 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 ++-
src/include/storage/standbydefs.h | 1 +
16 files changed, 99 insertions(+), 14 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..97ea882cf71 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2c1c6f88b74..8da8eff93e4 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7336,7 +7336,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index 00b21ede481..c25dbeadff3 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -16,6 +16,7 @@
*/
#include "postgres.h"
+#include "access/genam.h"
#include "access/table.h"
#include "access/xlog_internal.h"
#include "access/xlogutils.h"
@@ -233,6 +234,13 @@ repack_setup_logical_decoding(Oid relid)
EnsureLogicalDecodingEnabled();
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ accessSharedCatalogsInDecoding = false;
+
/*
* Neither prepare_write nor do_write callback nor update_progress is
* useful for us.
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 0f6b5df322c..16009fa75a4 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -1470,7 +1471,14 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ Oid dbid;
+
+ /*
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ LogStandbySnapshot(dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index fe6bfeba25e..0d415f5f8f2 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -39,6 +39,7 @@
#include <unistd.h>
#include <sys/stat.h>
+#include "access/genam.h"
#include "access/transam.h"
#include "access/xlog_internal.h"
#include "access/xlogrecovery.h"
@@ -1776,9 +1777,16 @@ ReplicationSlotReserveWal(void)
if (!RecoveryInProgress() && SlotIsLogical(slot))
{
XLogRecPtr flushptr;
+ Oid dbid;
- /* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ /*
+ * Make sure we have enough information to start.
+ *
+ * Only consider transactions of the current database if our plugin
+ * is not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ flushptr = LogStandbySnapshot(dbid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..49d1bf4bfac 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 755835d63bf..ae19982d88d 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -31,7 +31,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v52 08/10] Introduce an option to make logical replication database specific.
@ 2026-04-03 10:34 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-03 10:34 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch introduces the possibility for a backend to declare that its output
plugin does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in walsender involved in logical replication too, however
that would need thorough analysis of its output plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 ++--
src/backend/access/index/genam.c | 18 ++++++++++++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 ++
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/commands/repack_worker.c | 8 +++++++
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/snapbuild.c | 10 ++++++++-
src/backend/replication/slot.c | 12 +++++++++--
src/backend/storage/ipc/procarray.c | 23 ++++++++++++++++++++-
src/backend/storage/ipc/standby.c | 14 +++++++++++--
src/include/access/genam.h | 8 +++++++
src/include/access/xlog_internal.h | 2 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 ++-
src/include/storage/standbydefs.h | 1 +
16 files changed, 99 insertions(+), 14 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..df092dc999a 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2c1c6f88b74..8da8eff93e4 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7336,7 +7336,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index c85166ba849..ff34e246469 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -16,6 +16,7 @@
*/
#include "postgres.h"
+#include "access/genam.h"
#include "access/table.h"
#include "access/xlog_internal.h"
#include "access/xlogutils.h"
@@ -237,6 +238,13 @@ repack_setup_logical_decoding(Oid relid)
EnsureLogicalDecodingEnabled();
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ accessSharedCatalogsInDecoding = false;
+
/*
* Neither prepare_write nor do_write callback nor update_progress is
* useful for us.
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..2e3926e1d13 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -1465,7 +1466,14 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ Oid dbid;
+
+ /*
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ LogStandbySnapshot(dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..d553bd5dbff 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -39,6 +39,7 @@
#include <unistd.h>
#include <sys/stat.h>
+#include "access/genam.h"
#include "access/transam.h"
#include "access/xlog_internal.h"
#include "access/xlogrecovery.h"
@@ -1760,9 +1761,16 @@ ReplicationSlotReserveWal(void)
if (!RecoveryInProgress() && SlotIsLogical(slot))
{
XLogRecPtr flushptr;
+ Oid dbid;
- /* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ /*
+ * Make sure we have enough information to start.
+ *
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ flushptr = LogStandbySnapshot(dbid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 755835d63bf..ae19982d88d 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -31,7 +31,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--gp2pyozrd5pweboh
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v52-0009-Reserve-replication-slots-specifically-for-REPAC.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v51 08/10] Introduce an option to make logical replication database specific.
@ 2026-04-03 10:34 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-03 10:34 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch introduces the possibility for a backend to declare that its output
plugin does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in walsender involved in logical replication too, however
that would need thorough analysis of its output plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 ++--
src/backend/access/index/genam.c | 18 ++++++++++++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 ++
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/commands/repack_worker.c | 8 +++++++
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/snapbuild.c | 10 ++++++++-
src/backend/replication/slot.c | 12 +++++++++--
src/backend/storage/ipc/procarray.c | 23 ++++++++++++++++++++-
src/backend/storage/ipc/standby.c | 14 +++++++++++--
src/include/access/genam.h | 8 +++++++
src/include/access/xlog_internal.h | 2 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 ++-
src/include/storage/standbydefs.h | 1 +
16 files changed, 99 insertions(+), 14 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..df092dc999a 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2c1c6f88b74..8da8eff93e4 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7336,7 +7336,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index c85166ba849..ff34e246469 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -16,6 +16,7 @@
*/
#include "postgres.h"
+#include "access/genam.h"
#include "access/table.h"
#include "access/xlog_internal.h"
#include "access/xlogutils.h"
@@ -237,6 +238,13 @@ repack_setup_logical_decoding(Oid relid)
EnsureLogicalDecodingEnabled();
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ accessSharedCatalogsInDecoding = false;
+
/*
* Neither prepare_write nor do_write callback nor update_progress is
* useful for us.
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..2e3926e1d13 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -1465,7 +1466,14 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ Oid dbid;
+
+ /*
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ LogStandbySnapshot(dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..d553bd5dbff 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -39,6 +39,7 @@
#include <unistd.h>
#include <sys/stat.h>
+#include "access/genam.h"
#include "access/transam.h"
#include "access/xlog_internal.h"
#include "access/xlogrecovery.h"
@@ -1760,9 +1761,16 @@ ReplicationSlotReserveWal(void)
if (!RecoveryInProgress() && SlotIsLogical(slot))
{
XLogRecPtr flushptr;
+ Oid dbid;
- /* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ /*
+ * Make sure we have enough information to start.
+ *
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ flushptr = LogStandbySnapshot(dbid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 755835d63bf..ae19982d88d 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -31,7 +31,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--r2slln3zpmilwu22
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v51-0009-Reserve-replication-slots-specifically-for-REPAC.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH] Introduce an option to make logical replication database specific.
@ 2026-04-03 10:34 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-03 10:34 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch introduces the possibility for a backend to declare that its output
plugin does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in walsender involved in logical replication too, however
that would need thorough analysis of its output plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 ++--
src/backend/access/index/genam.c | 18 ++++++++++++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 ++
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/commands/repack_worker.c | 8 +++++++
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/snapbuild.c | 10 ++++++++-
src/backend/replication/slot.c | 12 +++++++++--
src/backend/storage/ipc/procarray.c | 23 ++++++++++++++++++++-
src/backend/storage/ipc/standby.c | 14 +++++++++++--
src/include/access/genam.h | 8 +++++++
src/include/access/xlog_internal.h | 2 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 ++-
src/include/storage/standbydefs.h | 1 +
16 files changed, 99 insertions(+), 14 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..97ea882cf71 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2c1c6f88b74..8da8eff93e4 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7336,7 +7336,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index 00b21ede481..c25dbeadff3 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -16,6 +16,7 @@
*/
#include "postgres.h"
+#include "access/genam.h"
#include "access/table.h"
#include "access/xlog_internal.h"
#include "access/xlogutils.h"
@@ -233,6 +234,13 @@ repack_setup_logical_decoding(Oid relid)
EnsureLogicalDecodingEnabled();
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ accessSharedCatalogsInDecoding = false;
+
/*
* Neither prepare_write nor do_write callback nor update_progress is
* useful for us.
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 0f6b5df322c..16009fa75a4 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -1470,7 +1471,14 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ Oid dbid;
+
+ /*
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ LogStandbySnapshot(dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index fe6bfeba25e..0d415f5f8f2 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -39,6 +39,7 @@
#include <unistd.h>
#include <sys/stat.h>
+#include "access/genam.h"
#include "access/transam.h"
#include "access/xlog_internal.h"
#include "access/xlogrecovery.h"
@@ -1776,9 +1777,16 @@ ReplicationSlotReserveWal(void)
if (!RecoveryInProgress() && SlotIsLogical(slot))
{
XLogRecPtr flushptr;
+ Oid dbid;
- /* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ /*
+ * Make sure we have enough information to start.
+ *
+ * Only consider transactions of the current database if our plugin
+ * is not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ flushptr = LogStandbySnapshot(dbid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..49d1bf4bfac 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 755835d63bf..ae19982d88d 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -31,7 +31,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v50 7/8] Introduce an option to make logical replication database specific.
@ 2026-04-03 10:34 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-03 10:34 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch introduces the possibility for a backend to declare that its output
plugin does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in walsender involved in logical replication too, however
that would need thorough analysis of its output plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 ++--
src/backend/access/index/genam.c | 18 ++++++++++++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 ++
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/commands/repack_worker.c | 8 +++++++
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/snapbuild.c | 10 ++++++++-
src/backend/replication/slot.c | 12 +++++++++--
src/backend/storage/ipc/procarray.c | 23 ++++++++++++++++++++-
src/backend/storage/ipc/standby.c | 14 +++++++++++--
src/include/access/genam.h | 8 +++++++
src/include/access/xlog_internal.h | 2 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 ++-
src/include/storage/standbydefs.h | 1 +
16 files changed, 99 insertions(+), 14 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..df092dc999a 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2c1c6f88b74..8da8eff93e4 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7336,7 +7336,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index c85166ba849..ff34e246469 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -16,6 +16,7 @@
*/
#include "postgres.h"
+#include "access/genam.h"
#include "access/table.h"
#include "access/xlog_internal.h"
#include "access/xlogutils.h"
@@ -237,6 +238,13 @@ repack_setup_logical_decoding(Oid relid)
EnsureLogicalDecodingEnabled();
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ accessSharedCatalogsInDecoding = false;
+
/*
* Neither prepare_write nor do_write callback nor update_progress is
* useful for us.
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..2e3926e1d13 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -1465,7 +1466,14 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ Oid dbid;
+
+ /*
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ LogStandbySnapshot(dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..d553bd5dbff 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -39,6 +39,7 @@
#include <unistd.h>
#include <sys/stat.h>
+#include "access/genam.h"
#include "access/transam.h"
#include "access/xlog_internal.h"
#include "access/xlogrecovery.h"
@@ -1760,9 +1761,16 @@ ReplicationSlotReserveWal(void)
if (!RecoveryInProgress() && SlotIsLogical(slot))
{
XLogRecPtr flushptr;
+ Oid dbid;
- /* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ /*
+ * Make sure we have enough information to start.
+ *
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ flushptr = LogStandbySnapshot(dbid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 755835d63bf..ae19982d88d 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -31,7 +31,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--brnevsqjnuzpyok4
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v50-0008-Reserve-replication-slots-specifically-for-REPAC.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v51 08/10] Introduce an option to make logical replication database specific.
@ 2026-04-03 10:34 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-03 10:34 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch introduces the possibility for a backend to declare that its output
plugin does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in walsender involved in logical replication too, however
that would need thorough analysis of its output plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 ++--
src/backend/access/index/genam.c | 18 ++++++++++++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 ++
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/commands/repack_worker.c | 8 +++++++
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/snapbuild.c | 10 ++++++++-
src/backend/replication/slot.c | 12 +++++++++--
src/backend/storage/ipc/procarray.c | 23 ++++++++++++++++++++-
src/backend/storage/ipc/standby.c | 14 +++++++++++--
src/include/access/genam.h | 8 +++++++
src/include/access/xlog_internal.h | 2 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 ++-
src/include/storage/standbydefs.h | 1 +
16 files changed, 99 insertions(+), 14 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..df092dc999a 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2c1c6f88b74..8da8eff93e4 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7336,7 +7336,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index c85166ba849..ff34e246469 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -16,6 +16,7 @@
*/
#include "postgres.h"
+#include "access/genam.h"
#include "access/table.h"
#include "access/xlog_internal.h"
#include "access/xlogutils.h"
@@ -237,6 +238,13 @@ repack_setup_logical_decoding(Oid relid)
EnsureLogicalDecodingEnabled();
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ accessSharedCatalogsInDecoding = false;
+
/*
* Neither prepare_write nor do_write callback nor update_progress is
* useful for us.
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..2e3926e1d13 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -1465,7 +1466,14 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ Oid dbid;
+
+ /*
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ LogStandbySnapshot(dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..d553bd5dbff 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -39,6 +39,7 @@
#include <unistd.h>
#include <sys/stat.h>
+#include "access/genam.h"
#include "access/transam.h"
#include "access/xlog_internal.h"
#include "access/xlogrecovery.h"
@@ -1760,9 +1761,16 @@ ReplicationSlotReserveWal(void)
if (!RecoveryInProgress() && SlotIsLogical(slot))
{
XLogRecPtr flushptr;
+ Oid dbid;
- /* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ /*
+ * Make sure we have enough information to start.
+ *
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ flushptr = LogStandbySnapshot(dbid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 755835d63bf..ae19982d88d 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -31,7 +31,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--r2slln3zpmilwu22
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v51-0009-Reserve-replication-slots-specifically-for-REPAC.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v52 08/10] Introduce an option to make logical replication database specific.
@ 2026-04-03 10:34 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-03 10:34 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch introduces the possibility for a backend to declare that its output
plugin does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in walsender involved in logical replication too, however
that would need thorough analysis of its output plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 ++--
src/backend/access/index/genam.c | 18 ++++++++++++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 ++
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/commands/repack_worker.c | 8 +++++++
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/snapbuild.c | 10 ++++++++-
src/backend/replication/slot.c | 12 +++++++++--
src/backend/storage/ipc/procarray.c | 23 ++++++++++++++++++++-
src/backend/storage/ipc/standby.c | 14 +++++++++++--
src/include/access/genam.h | 8 +++++++
src/include/access/xlog_internal.h | 2 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 ++-
src/include/storage/standbydefs.h | 1 +
16 files changed, 99 insertions(+), 14 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..df092dc999a 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2c1c6f88b74..8da8eff93e4 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7336,7 +7336,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index c85166ba849..ff34e246469 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -16,6 +16,7 @@
*/
#include "postgres.h"
+#include "access/genam.h"
#include "access/table.h"
#include "access/xlog_internal.h"
#include "access/xlogutils.h"
@@ -237,6 +238,13 @@ repack_setup_logical_decoding(Oid relid)
EnsureLogicalDecodingEnabled();
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ accessSharedCatalogsInDecoding = false;
+
/*
* Neither prepare_write nor do_write callback nor update_progress is
* useful for us.
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..2e3926e1d13 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -1465,7 +1466,14 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ Oid dbid;
+
+ /*
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ LogStandbySnapshot(dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..d553bd5dbff 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -39,6 +39,7 @@
#include <unistd.h>
#include <sys/stat.h>
+#include "access/genam.h"
#include "access/transam.h"
#include "access/xlog_internal.h"
#include "access/xlogrecovery.h"
@@ -1760,9 +1761,16 @@ ReplicationSlotReserveWal(void)
if (!RecoveryInProgress() && SlotIsLogical(slot))
{
XLogRecPtr flushptr;
+ Oid dbid;
- /* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ /*
+ * Make sure we have enough information to start.
+ *
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ flushptr = LogStandbySnapshot(dbid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 755835d63bf..ae19982d88d 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -31,7 +31,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--gp2pyozrd5pweboh
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v52-0009-Reserve-replication-slots-specifically-for-REPAC.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v50 7/8] Introduce an option to make logical replication database specific.
@ 2026-04-03 10:34 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-03 10:34 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch introduces the possibility for a backend to declare that its output
plugin does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in walsender involved in logical replication too, however
that would need thorough analysis of its output plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 ++--
src/backend/access/index/genam.c | 18 ++++++++++++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 ++
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/commands/repack_worker.c | 8 +++++++
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/snapbuild.c | 10 ++++++++-
src/backend/replication/slot.c | 12 +++++++++--
src/backend/storage/ipc/procarray.c | 23 ++++++++++++++++++++-
src/backend/storage/ipc/standby.c | 14 +++++++++++--
src/include/access/genam.h | 8 +++++++
src/include/access/xlog_internal.h | 2 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 ++-
src/include/storage/standbydefs.h | 1 +
16 files changed, 99 insertions(+), 14 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..df092dc999a 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2c1c6f88b74..8da8eff93e4 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7336,7 +7336,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index c85166ba849..ff34e246469 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -16,6 +16,7 @@
*/
#include "postgres.h"
+#include "access/genam.h"
#include "access/table.h"
#include "access/xlog_internal.h"
#include "access/xlogutils.h"
@@ -237,6 +238,13 @@ repack_setup_logical_decoding(Oid relid)
EnsureLogicalDecodingEnabled();
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ accessSharedCatalogsInDecoding = false;
+
/*
* Neither prepare_write nor do_write callback nor update_progress is
* useful for us.
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..2e3926e1d13 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -1465,7 +1466,14 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ Oid dbid;
+
+ /*
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ LogStandbySnapshot(dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..d553bd5dbff 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -39,6 +39,7 @@
#include <unistd.h>
#include <sys/stat.h>
+#include "access/genam.h"
#include "access/transam.h"
#include "access/xlog_internal.h"
#include "access/xlogrecovery.h"
@@ -1760,9 +1761,16 @@ ReplicationSlotReserveWal(void)
if (!RecoveryInProgress() && SlotIsLogical(slot))
{
XLogRecPtr flushptr;
+ Oid dbid;
- /* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ /*
+ * Make sure we have enough information to start.
+ *
+ * Only consider transactions of the current database if our plugin is
+ * not supposed to access shared catalogs.
+ */
+ dbid = accessSharedCatalogsInDecoding ? InvalidOid : MyDatabaseId;
+ flushptr = LogStandbySnapshot(dbid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 755835d63bf..ae19982d88d 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -31,7 +31,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--brnevsqjnuzpyok4
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v50-0008-Reserve-replication-slots-specifically-for-REPAC.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v53 1/7] Introduce an option to make logical replication database specific.
@ 2026-04-04 15:16 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-04 15:16 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 8 +++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 8 ++-
src/backend/replication/logical/logical.c | 3 ++
src/backend/replication/logical/snapbuild.c | 59 ++++++++++++++++++---
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 +++++++-
src/backend/storage/ipc/standby.c | 14 ++++-
src/include/access/genam.h | 7 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
20 files changed, 131 insertions(+), 21 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..44df2605068 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -394,6 +394,14 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 9e8999bbb61..1a6c1456d2c 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7731,7 +7731,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 57aaef57c61..4299d0bc867 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -381,7 +381,13 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20d0c542f3..8ceaf64d164 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -285,6 +285,9 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /* Assume shared catalog access. The startup callback can change it. */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..a6738e120c7 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -154,6 +155,14 @@
static ResourceOwner SavedResourceOwnerDuringExport = NULL;
static bool ExportInProgress = false;
+/*
+ * If a backend is going to do logical decoding and the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ->committed and ->catchange manipulation */
static void SnapBuildPurgeOlderTxn(SnapBuild *builder);
@@ -170,7 +179,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running, bool db_specific);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -1136,7 +1146,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1149,7 +1160,7 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
if (builder->state < SNAPBUILD_CONSISTENT)
{
/* returns false if there's no point in performing cleanup just yet */
- if (!SnapBuildFindSnapshot(builder, lsn, running))
+ if (!SnapBuildFindSnapshot(builder, lsn, running, db_specific))
return;
}
else
@@ -1166,8 +1177,14 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* (see SnapBuildCommitTxn). Because of this, xmax can be lower than
* xmin, which looks odd but is correct and actually more efficient, since
* we hit fast paths in heapam_visibility.c.
+ *
+ * If database specific transaction info was used during startup, the info
+ * for the whole cluster can make xmin go backwards. That would be bad
+ * because we might no longer have older XIDs in ->committed.
*/
- builder->xmin = running->oldestRunningXid;
+ if (!db_specific ||
+ NormalTransactionIdFollows(running->oldestRunningXid, builder->xmin))
+ builder->xmin = running->oldestRunningXid;
/* Remove transactions we don't need to keep track off anymore */
SnapBuildPurgeOlderTxn(builder);
@@ -1182,7 +1199,11 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* the record we're reading now.
*/
xmin = ReorderBufferGetOldestXmin(builder->reorder);
- if (xmin == InvalidTransactionId)
+
+ /*
+ * Like above, do not let slot xmin go backwards.
+ */
+ if (xmin == InvalidTransactionId && !db_specific)
xmin = running->oldestRunningXid;
elog(DEBUG3, "xmin: %u, xmax: %u, oldest running: %u, oldest xmin: %u",
builder->xmin, builder->xmax, running->oldestRunningXid, xmin);
@@ -1238,7 +1259,8 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* using the xl_running_xacts record.
*/
static bool
-SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
/* ---
* Build catalog decoding snapshot incrementally using information about
@@ -1265,6 +1287,25 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
* ---
*/
+ if (db_specific)
+ {
+ /*
+ * If we must only keep track of transactions running in the current
+ * database, we need transaction info from exactly that database.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+ return false;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ accessSharedCatalogsInDecoding = false;
+ }
+
/*
* xl_running_xacts record is older than what we can use, we might not
* have all necessary catalog rows anymore.
@@ -1465,7 +1506,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..9533515a63b 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1762,7 +1762,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..c9a52277be1 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,13 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+
+/*
+ * Keep track of whether logical decoding in this backend promised not to
+ * access shared catalogs, as a safety check. Somewhat misplaced, but ...
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index a22a83a2f23..d02530a912a 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -92,7 +92,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- xl_running_xacts *running);
+ xl_running_xacts *running,
+ bool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--qr3jlalmmcpkiodg
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v53-0002-Fix-a-few-problems-in-index-build-progress-repor.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH] Introduce an option to make logical replication database specific.
@ 2026-04-04 15:16 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-04 15:16 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 18 +++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 8 ++-
src/backend/replication/logical/logical.c | 5 ++
src/backend/replication/logical/snapbuild.c | 52 ++++++++++++++++---
.../pgoutput_repack/pgoutput_repack.c | 7 +++
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 +++++++-
src/backend/storage/ipc/standby.c | 14 ++++-
src/include/access/genam.h | 8 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
21 files changed, 144 insertions(+), 21 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..df092dc999a 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 9e8999bbb61..1a6c1456d2c 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7731,7 +7731,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 2be5d8d4bd9..1353d004aac 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -382,7 +382,13 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20a0fe70ad..89043a03497 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -289,6 +289,11 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /*
+ * Assume true for safety, the startup callback can change that.
+ */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..054a7b16f43 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -170,7 +171,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running, bool db_specific);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -1136,7 +1138,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1149,7 +1152,7 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
if (builder->state < SNAPBUILD_CONSISTENT)
{
/* returns false if there's no point in performing cleanup just yet */
- if (!SnapBuildFindSnapshot(builder, lsn, running))
+ if (!SnapBuildFindSnapshot(builder, lsn, running, db_specific))
return;
}
else
@@ -1166,8 +1169,13 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* (see SnapBuildCommitTxn). Because of this, xmax can be lower than
* xmin, which looks odd but is correct and actually more efficient, since
* we hit fast paths in heapam_visibility.c.
+ *
+ * If database specific transaction info was used during startup, the info
+ * for the whole cluster can make xmin go backwards. That would be bad
+ * because we might no longer have older XIDs in ->committed.
*/
- builder->xmin = running->oldestRunningXid;
+ if (NormalTransactionIdFollows(running->oldestRunningXid, builder->xmin))
+ builder->xmin = running->oldestRunningXid;
/* Remove transactions we don't need to keep track off anymore */
SnapBuildPurgeOlderTxn(builder);
@@ -1182,7 +1190,10 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* the record we're reading now.
*/
xmin = ReorderBufferGetOldestXmin(builder->reorder);
- if (xmin == InvalidTransactionId)
+ /*
+ * Like above, do not let slot xmin go backwards.
+ */
+ if (xmin == InvalidTransactionId && !db_specific)
xmin = running->oldestRunningXid;
elog(DEBUG3, "xmin: %u, xmax: %u, oldest running: %u, oldest xmin: %u",
builder->xmin, builder->xmax, running->oldestRunningXid, xmin);
@@ -1238,7 +1249,8 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* using the xl_running_xacts record.
*/
static bool
-SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
/* ---
* Build catalog decoding snapshot incrementally using information about
@@ -1265,6 +1277,28 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
* ---
*/
+ if (db_specific)
+ {
+ /*
+ * If we should only keep track of transactions running in the current
+ * database, we need transaction info from exactly that
+ * database. Invalid 'dbid' (all databases) would satisfy our needs
+ * too, but it could make us wait unnecessarily for completion of
+ * transactions running in other databases.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+ return false;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ accessSharedCatalogsInDecoding = false;
+ }
+
/*
* xl_running_xacts record is older than what we can use, we might not
* have all necessary catalog rows anymore.
@@ -1465,7 +1499,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/pgoutput_repack/pgoutput_repack.c b/src/backend/replication/pgoutput_repack/pgoutput_repack.c
index 221260ca0a8..bb3a880a4c3 100644
--- a/src/backend/replication/pgoutput_repack/pgoutput_repack.c
+++ b/src/backend/replication/pgoutput_repack/pgoutput_repack.c
@@ -52,6 +52,13 @@ repack_startup(LogicalDecodingContext *ctx, OutputPluginOptions *opt,
/* Probably unnecessary, as we don't use the SQL interface ... */
opt->output_type = OUTPUT_PLUGIN_BINARY_OUTPUT;
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ opt->need_shared_catalogs = false;
+
if (ctx->output_plugin_options != NIL)
{
ereport(ERROR,
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..9533515a63b 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1762,7 +1762,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index ccded021433..82552a97997 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -93,7 +93,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
struct xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- struct xl_running_xacts *running);
+ struct xl_running_xacts *running,
+ bool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v53 1/7] Introduce an option to make logical replication database specific.
@ 2026-04-04 15:16 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-04 15:16 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 8 +++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 8 ++-
src/backend/replication/logical/logical.c | 3 ++
src/backend/replication/logical/snapbuild.c | 59 ++++++++++++++++++---
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 +++++++-
src/backend/storage/ipc/standby.c | 14 ++++-
src/include/access/genam.h | 7 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
20 files changed, 131 insertions(+), 21 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..44df2605068 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -394,6 +394,14 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 9e8999bbb61..1a6c1456d2c 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7731,7 +7731,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 57aaef57c61..4299d0bc867 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -381,7 +381,13 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20d0c542f3..8ceaf64d164 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -285,6 +285,9 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /* Assume shared catalog access. The startup callback can change it. */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..a6738e120c7 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -154,6 +155,14 @@
static ResourceOwner SavedResourceOwnerDuringExport = NULL;
static bool ExportInProgress = false;
+/*
+ * If a backend is going to do logical decoding and the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ->committed and ->catchange manipulation */
static void SnapBuildPurgeOlderTxn(SnapBuild *builder);
@@ -170,7 +179,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running, bool db_specific);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -1136,7 +1146,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1149,7 +1160,7 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
if (builder->state < SNAPBUILD_CONSISTENT)
{
/* returns false if there's no point in performing cleanup just yet */
- if (!SnapBuildFindSnapshot(builder, lsn, running))
+ if (!SnapBuildFindSnapshot(builder, lsn, running, db_specific))
return;
}
else
@@ -1166,8 +1177,14 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* (see SnapBuildCommitTxn). Because of this, xmax can be lower than
* xmin, which looks odd but is correct and actually more efficient, since
* we hit fast paths in heapam_visibility.c.
+ *
+ * If database specific transaction info was used during startup, the info
+ * for the whole cluster can make xmin go backwards. That would be bad
+ * because we might no longer have older XIDs in ->committed.
*/
- builder->xmin = running->oldestRunningXid;
+ if (!db_specific ||
+ NormalTransactionIdFollows(running->oldestRunningXid, builder->xmin))
+ builder->xmin = running->oldestRunningXid;
/* Remove transactions we don't need to keep track off anymore */
SnapBuildPurgeOlderTxn(builder);
@@ -1182,7 +1199,11 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* the record we're reading now.
*/
xmin = ReorderBufferGetOldestXmin(builder->reorder);
- if (xmin == InvalidTransactionId)
+
+ /*
+ * Like above, do not let slot xmin go backwards.
+ */
+ if (xmin == InvalidTransactionId && !db_specific)
xmin = running->oldestRunningXid;
elog(DEBUG3, "xmin: %u, xmax: %u, oldest running: %u, oldest xmin: %u",
builder->xmin, builder->xmax, running->oldestRunningXid, xmin);
@@ -1238,7 +1259,8 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* using the xl_running_xacts record.
*/
static bool
-SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
/* ---
* Build catalog decoding snapshot incrementally using information about
@@ -1265,6 +1287,25 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
* ---
*/
+ if (db_specific)
+ {
+ /*
+ * If we must only keep track of transactions running in the current
+ * database, we need transaction info from exactly that database.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+ return false;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ accessSharedCatalogsInDecoding = false;
+ }
+
/*
* xl_running_xacts record is older than what we can use, we might not
* have all necessary catalog rows anymore.
@@ -1465,7 +1506,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..9533515a63b 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1762,7 +1762,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..c9a52277be1 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,13 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+
+/*
+ * Keep track of whether logical decoding in this backend promised not to
+ * access shared catalogs, as a safety check. Somewhat misplaced, but ...
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index a22a83a2f23..d02530a912a 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -92,7 +92,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- xl_running_xacts *running);
+ xl_running_xacts *running,
+ bool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--qr3jlalmmcpkiodg
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v53-0002-Fix-a-few-problems-in-index-build-progress-repor.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH] Introduce an option to make logical replication database specific.
@ 2026-04-04 15:16 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-04 15:16 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 18 +++++++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 8 ++-
src/backend/replication/logical/logical.c | 5 ++
src/backend/replication/logical/snapbuild.c | 52 ++++++++++++++++---
.../pgoutput_repack/pgoutput_repack.c | 7 +++
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 +++++++-
src/backend/storage/ipc/standby.c | 14 ++++-
src/include/access/genam.h | 8 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
21 files changed, 144 insertions(+), 21 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..df092dc999a 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -37,6 +37,14 @@
#include "utils/ruleutils.h"
#include "utils/snapmgr.h"
+/*
+ * If a backend is going to do logical decoding and if the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ----------------------------------------------------------------
* general access method routines
@@ -394,6 +402,16 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ *
+ * XXX Should this be ereport(ERROR) ?
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 9e8999bbb61..1a6c1456d2c 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7731,7 +7731,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 2be5d8d4bd9..1353d004aac 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -382,7 +382,13 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20a0fe70ad..89043a03497 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -289,6 +289,11 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /*
+ * Assume true for safety, the startup callback can change that.
+ */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..054a7b16f43 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -170,7 +171,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running, bool db_specific);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -1136,7 +1138,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1149,7 +1152,7 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
if (builder->state < SNAPBUILD_CONSISTENT)
{
/* returns false if there's no point in performing cleanup just yet */
- if (!SnapBuildFindSnapshot(builder, lsn, running))
+ if (!SnapBuildFindSnapshot(builder, lsn, running, db_specific))
return;
}
else
@@ -1166,8 +1169,13 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* (see SnapBuildCommitTxn). Because of this, xmax can be lower than
* xmin, which looks odd but is correct and actually more efficient, since
* we hit fast paths in heapam_visibility.c.
+ *
+ * If database specific transaction info was used during startup, the info
+ * for the whole cluster can make xmin go backwards. That would be bad
+ * because we might no longer have older XIDs in ->committed.
*/
- builder->xmin = running->oldestRunningXid;
+ if (NormalTransactionIdFollows(running->oldestRunningXid, builder->xmin))
+ builder->xmin = running->oldestRunningXid;
/* Remove transactions we don't need to keep track off anymore */
SnapBuildPurgeOlderTxn(builder);
@@ -1182,7 +1190,10 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* the record we're reading now.
*/
xmin = ReorderBufferGetOldestXmin(builder->reorder);
- if (xmin == InvalidTransactionId)
+ /*
+ * Like above, do not let slot xmin go backwards.
+ */
+ if (xmin == InvalidTransactionId && !db_specific)
xmin = running->oldestRunningXid;
elog(DEBUG3, "xmin: %u, xmax: %u, oldest running: %u, oldest xmin: %u",
builder->xmin, builder->xmax, running->oldestRunningXid, xmin);
@@ -1238,7 +1249,8 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* using the xl_running_xacts record.
*/
static bool
-SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
/* ---
* Build catalog decoding snapshot incrementally using information about
@@ -1265,6 +1277,28 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
* ---
*/
+ if (db_specific)
+ {
+ /*
+ * If we should only keep track of transactions running in the current
+ * database, we need transaction info from exactly that
+ * database. Invalid 'dbid' (all databases) would satisfy our needs
+ * too, but it could make us wait unnecessarily for completion of
+ * transactions running in other databases.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+ return false;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ accessSharedCatalogsInDecoding = false;
+ }
+
/*
* xl_running_xacts record is older than what we can use, we might not
* have all necessary catalog rows anymore.
@@ -1465,7 +1499,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/pgoutput_repack/pgoutput_repack.c b/src/backend/replication/pgoutput_repack/pgoutput_repack.c
index 221260ca0a8..bb3a880a4c3 100644
--- a/src/backend/replication/pgoutput_repack/pgoutput_repack.c
+++ b/src/backend/replication/pgoutput_repack/pgoutput_repack.c
@@ -52,6 +52,13 @@ repack_startup(LogicalDecodingContext *ctx, OutputPluginOptions *opt,
/* Probably unnecessary, as we don't use the SQL interface ... */
opt->output_type = OUTPUT_PLUGIN_BINARY_OUTPUT;
+ /*
+ * By declaring that our output plugin does not need shared catalogs, we
+ * avoid waiting for completion of transactions running in other databases
+ * than the one we're connected to.
+ */
+ opt->need_shared_catalogs = false;
+
if (ctx->output_plugin_options != NIL)
{
ereport(ERROR,
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..9533515a63b 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1762,7 +1762,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..56c573399ab 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,14 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+/*
+ * Is the backend interested in shared catalogs when performing logical
+ * decoding?
+ *
+ * XXX Is there a better place for this declaration?
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index ccded021433..82552a97997 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -93,7 +93,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
struct xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- struct xl_running_xacts *running);
+ struct xl_running_xacts *running,
+ bool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH] Introduce an option to make logical replication database specific.
@ 2026-04-05 07:51 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-05 07:51 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 8 +++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 8 ++-
src/backend/replication/logical/logical.c | 3 ++
src/backend/replication/logical/snapbuild.c | 54 +++++++++++++++++++--
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 ++++++++-
src/backend/storage/ipc/standby.c | 14 +++++-
src/include/access/genam.h | 7 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
20 files changed, 128 insertions(+), 19 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..44df2605068 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -394,6 +394,14 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 9e8999bbb61..1a6c1456d2c 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7731,7 +7731,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 57aaef57c61..4299d0bc867 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -381,7 +381,13 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20d0c542f3..8ceaf64d164 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -285,6 +285,9 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /* Assume shared catalog access. The startup callback can change it. */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..8ef2326c66d 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -154,6 +155,14 @@
static ResourceOwner SavedResourceOwnerDuringExport = NULL;
static bool ExportInProgress = false;
+/*
+ * If a backend is going to do logical decoding and the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ->committed and ->catchange manipulation */
static void SnapBuildPurgeOlderTxn(SnapBuild *builder);
@@ -170,7 +179,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running, bool db_specific);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -1136,7 +1146,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1149,12 +1160,21 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
if (builder->state < SNAPBUILD_CONSISTENT)
{
/* returns false if there's no point in performing cleanup just yet */
- if (!SnapBuildFindSnapshot(builder, lsn, running))
+ if (!SnapBuildFindSnapshot(builder, lsn, running, db_specific))
return;
}
else
SnapBuildSerialize(builder, lsn);
+ /*
+ * If database specific transaction info was used during startup, the info
+ * for the whole cluster can make xmin go backwards. The code below
+ * probably does not expect that, let's wait with the cleanup for the next
+ * record.
+ */
+ if (!NormalTransactionIdFollows(running->oldestRunningXid, builder->xmin))
+ return;
+
/*
* Update range of interesting xids based on the running xacts
* information. We don't increase ->xmax using it, because once we are in
@@ -1238,7 +1258,8 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* using the xl_running_xacts record.
*/
static bool
-SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
/* ---
* Build catalog decoding snapshot incrementally using information about
@@ -1265,6 +1286,25 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
* ---
*/
+ if (db_specific)
+ {
+ /*
+ * If we must only keep track of transactions running in the current
+ * database, we need transaction info from exactly that database.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+ return false;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ accessSharedCatalogsInDecoding = false;
+ }
+
/*
* xl_running_xacts record is older than what we can use, we might not
* have all necessary catalog rows anymore.
@@ -1465,7 +1505,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..9533515a63b 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1762,7 +1762,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..c9a52277be1 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,13 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+
+/*
+ * Keep track of whether logical decoding in this backend promised not to
+ * access shared catalogs, as a safety check. Somewhat misplaced, but ...
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index ccded021433..f5f3edc63fd 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -93,7 +93,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
struct xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- struct xl_running_xacts *running);
+ struct xl_running_xacts *running,
+ boool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v54 1/5] Introduce an option to make logical replication database specific.
@ 2026-04-05 07:51 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-05 07:51 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 8 +++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 8 ++-
src/backend/replication/logical/logical.c | 3 ++
src/backend/replication/logical/snapbuild.c | 54 +++++++++++++++++++--
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 ++++++++-
src/backend/storage/ipc/standby.c | 14 +++++-
src/include/access/genam.h | 7 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
20 files changed, 128 insertions(+), 19 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..44df2605068 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -394,6 +394,14 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 9e8999bbb61..1a6c1456d2c 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7731,7 +7731,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 57aaef57c61..4299d0bc867 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -381,7 +381,13 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20d0c542f3..8ceaf64d164 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -285,6 +285,9 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /* Assume shared catalog access. The startup callback can change it. */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..8ef2326c66d 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -154,6 +155,14 @@
static ResourceOwner SavedResourceOwnerDuringExport = NULL;
static bool ExportInProgress = false;
+/*
+ * If a backend is going to do logical decoding and the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ->committed and ->catchange manipulation */
static void SnapBuildPurgeOlderTxn(SnapBuild *builder);
@@ -170,7 +179,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running, bool db_specific);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -1136,7 +1146,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1149,12 +1160,21 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
if (builder->state < SNAPBUILD_CONSISTENT)
{
/* returns false if there's no point in performing cleanup just yet */
- if (!SnapBuildFindSnapshot(builder, lsn, running))
+ if (!SnapBuildFindSnapshot(builder, lsn, running, db_specific))
return;
}
else
SnapBuildSerialize(builder, lsn);
+ /*
+ * If database specific transaction info was used during startup, the info
+ * for the whole cluster can make xmin go backwards. The code below
+ * probably does not expect that, let's wait with the cleanup for the next
+ * record.
+ */
+ if (!NormalTransactionIdFollows(running->oldestRunningXid, builder->xmin))
+ return;
+
/*
* Update range of interesting xids based on the running xacts
* information. We don't increase ->xmax using it, because once we are in
@@ -1238,7 +1258,8 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* using the xl_running_xacts record.
*/
static bool
-SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
/* ---
* Build catalog decoding snapshot incrementally using information about
@@ -1265,6 +1286,25 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
* ---
*/
+ if (db_specific)
+ {
+ /*
+ * If we must only keep track of transactions running in the current
+ * database, we need transaction info from exactly that database.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+ return false;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ accessSharedCatalogsInDecoding = false;
+ }
+
/*
* xl_running_xacts record is older than what we can use, we might not
* have all necessary catalog rows anymore.
@@ -1465,7 +1505,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..9533515a63b 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1762,7 +1762,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..c9a52277be1 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,13 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+
+/*
+ * Keep track of whether logical decoding in this backend promised not to
+ * access shared catalogs, as a safety check. Somewhat misplaced, but ...
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index a22a83a2f23..d02530a912a 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -92,7 +92,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- xl_running_xacts *running);
+ xl_running_xacts *running,
+ bool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--cdhh4t7ukb6tnjoq
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v54-0002-Rename-cluster.c-h-repack.c-h.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH] Introduce an option to make logical replication database specific.
@ 2026-04-05 07:51 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-05 07:51 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 8 +++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 8 ++-
src/backend/replication/logical/logical.c | 3 ++
src/backend/replication/logical/snapbuild.c | 54 +++++++++++++++++++--
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 ++++++++-
src/backend/storage/ipc/standby.c | 14 +++++-
src/include/access/genam.h | 7 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
20 files changed, 128 insertions(+), 19 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..44df2605068 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -394,6 +394,14 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 9e8999bbb61..1a6c1456d2c 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7731,7 +7731,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 57aaef57c61..4299d0bc867 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -381,7 +381,13 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20d0c542f3..8ceaf64d164 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -285,6 +285,9 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /* Assume shared catalog access. The startup callback can change it. */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..8ef2326c66d 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -154,6 +155,14 @@
static ResourceOwner SavedResourceOwnerDuringExport = NULL;
static bool ExportInProgress = false;
+/*
+ * If a backend is going to do logical decoding and the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ->committed and ->catchange manipulation */
static void SnapBuildPurgeOlderTxn(SnapBuild *builder);
@@ -170,7 +179,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running, bool db_specific);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -1136,7 +1146,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1149,12 +1160,21 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
if (builder->state < SNAPBUILD_CONSISTENT)
{
/* returns false if there's no point in performing cleanup just yet */
- if (!SnapBuildFindSnapshot(builder, lsn, running))
+ if (!SnapBuildFindSnapshot(builder, lsn, running, db_specific))
return;
}
else
SnapBuildSerialize(builder, lsn);
+ /*
+ * If database specific transaction info was used during startup, the info
+ * for the whole cluster can make xmin go backwards. The code below
+ * probably does not expect that, let's wait with the cleanup for the next
+ * record.
+ */
+ if (!NormalTransactionIdFollows(running->oldestRunningXid, builder->xmin))
+ return;
+
/*
* Update range of interesting xids based on the running xacts
* information. We don't increase ->xmax using it, because once we are in
@@ -1238,7 +1258,8 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* using the xl_running_xacts record.
*/
static bool
-SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
/* ---
* Build catalog decoding snapshot incrementally using information about
@@ -1265,6 +1286,25 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
* ---
*/
+ if (db_specific)
+ {
+ /*
+ * If we must only keep track of transactions running in the current
+ * database, we need transaction info from exactly that database.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+ return false;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ accessSharedCatalogsInDecoding = false;
+ }
+
/*
* xl_running_xacts record is older than what we can use, we might not
* have all necessary catalog rows anymore.
@@ -1465,7 +1505,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..9533515a63b 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1762,7 +1762,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..c9a52277be1 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,13 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+
+/*
+ * Keep track of whether logical decoding in this backend promised not to
+ * access shared catalogs, as a safety check. Somewhat misplaced, but ...
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index ccded021433..f5f3edc63fd 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -93,7 +93,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
struct xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- struct xl_running_xacts *running);
+ struct xl_running_xacts *running,
+ boool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH v54 1/5] Introduce an option to make logical replication database specific.
@ 2026-04-05 07:51 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-05 07:51 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 8 +++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 8 ++-
src/backend/replication/logical/logical.c | 3 ++
src/backend/replication/logical/snapbuild.c | 54 +++++++++++++++++++--
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 ++++++++-
src/backend/storage/ipc/standby.c | 14 +++++-
src/include/access/genam.h | 7 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
20 files changed, 128 insertions(+), 19 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..44df2605068 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -394,6 +394,14 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 9e8999bbb61..1a6c1456d2c 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7731,7 +7731,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 57aaef57c61..4299d0bc867 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -381,7 +381,13 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20d0c542f3..8ceaf64d164 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -285,6 +285,9 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /* Assume shared catalog access. The startup callback can change it. */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..8ef2326c66d 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -154,6 +155,14 @@
static ResourceOwner SavedResourceOwnerDuringExport = NULL;
static bool ExportInProgress = false;
+/*
+ * If a backend is going to do logical decoding and the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ->committed and ->catchange manipulation */
static void SnapBuildPurgeOlderTxn(SnapBuild *builder);
@@ -170,7 +179,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running, bool db_specific);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -1136,7 +1146,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1149,12 +1160,21 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
if (builder->state < SNAPBUILD_CONSISTENT)
{
/* returns false if there's no point in performing cleanup just yet */
- if (!SnapBuildFindSnapshot(builder, lsn, running))
+ if (!SnapBuildFindSnapshot(builder, lsn, running, db_specific))
return;
}
else
SnapBuildSerialize(builder, lsn);
+ /*
+ * If database specific transaction info was used during startup, the info
+ * for the whole cluster can make xmin go backwards. The code below
+ * probably does not expect that, let's wait with the cleanup for the next
+ * record.
+ */
+ if (!NormalTransactionIdFollows(running->oldestRunningXid, builder->xmin))
+ return;
+
/*
* Update range of interesting xids based on the running xacts
* information. We don't increase ->xmax using it, because once we are in
@@ -1238,7 +1258,8 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
* using the xl_running_xacts record.
*/
static bool
-SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
/* ---
* Build catalog decoding snapshot incrementally using information about
@@ -1265,6 +1286,25 @@ SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *runn
* ---
*/
+ if (db_specific)
+ {
+ /*
+ * If we must only keep track of transactions running in the current
+ * database, we need transaction info from exactly that database.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+ return false;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ accessSharedCatalogsInDecoding = false;
+ }
+
/*
* xl_running_xacts record is older than what we can use, we might not
* have all necessary catalog rows anymore.
@@ -1465,7 +1505,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index a9092fc2382..9533515a63b 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1762,7 +1762,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cc207cb56e3..92ed34128e5 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2631,9 +2631,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2708,6 +2710,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2758,6 +2772,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2791,6 +2811,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..c653ea742bc 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,12 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that database.
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1323,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1367,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..c9a52277be1 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,13 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+
+/*
+ * Keep track of whether logical decoding in this backend promised not to
+ * access shared catalogs, as a safety check. Somewhat misplaced, but ...
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index a22a83a2f23..d02530a912a 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -92,7 +92,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- xl_running_xacts *running);
+ xl_running_xacts *running,
+ bool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index abdf021e66e..377b3060b9f 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -49,7 +49,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--cdhh4t7ukb6tnjoq
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v54-0002-Rename-cluster.c-h-repack.c-h.patch"
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH] Introduce an option to make logical replication database specific.
@ 2026-04-06 08:49 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-06 08:49 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 8 +++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 16 +++++-
src/backend/replication/logical/logical.c | 3 +
src/backend/replication/logical/snapbuild.c | 64 ++++++++++++++++++++-
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 +++++++-
src/backend/storage/ipc/standby.c | 24 +++++++-
src/include/access/genam.h | 7 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
20 files changed, 157 insertions(+), 18 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..44df2605068 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -394,6 +394,14 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index b82af9a85c0..3f08a832ca6 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7735,7 +7735,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 57aaef57c61..49a59605515 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -381,7 +381,15 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database. This is
+ * currently the only use case for database-specific running
+ * xacts record.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
@@ -391,8 +399,12 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
* all running transactions which includes prepared ones,
* while shutdown checkpoints just know that no non-prepared
* transactions are in progress.
+ *
+ * The database-specific records might work here too, but it's
+ * not their purpose.
*/
- ReorderBufferAbortOld(ctx->reorder, running->oldestRunningXid);
+ if (!OidIsValid(running->dbid))
+ ReorderBufferAbortOld(ctx->reorder, running->oldestRunningXid);
}
break;
case XLOG_STANDBY_LOCK:
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20d0c542f3..8ceaf64d164 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -285,6 +285,9 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /* Assume shared catalog access. The startup callback can change it. */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..a10e8c0ca77 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -154,6 +155,14 @@
static ResourceOwner SavedResourceOwnerDuringExport = NULL;
static bool ExportInProgress = false;
+/*
+ * If a backend is going to do logical decoding and the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ->committed and ->catchange manipulation */
static void SnapBuildPurgeOlderTxn(SnapBuild *builder);
@@ -170,7 +179,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -226,6 +236,9 @@ AllocateSnapshotBuilder(ReorderBuffer *reorder,
MemoryContextSwitchTo(oldcontext);
+ /* The default is that shared catalog are used. */
+ accessSharedCatalogsInDecoding = true;
+
return builder;
}
@@ -244,6 +257,9 @@ FreeSnapshotBuilder(SnapBuild *builder)
builder->snapshot = NULL;
}
+ /* The default is that shared catalog are used. */
+ accessSharedCatalogsInDecoding = true;
+
/* other resources are deallocated via memory context reset */
MemoryContextDelete(context);
}
@@ -1136,7 +1152,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1148,6 +1165,33 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
*/
if (builder->state < SNAPBUILD_CONSISTENT)
{
+ /*
+ * To reduce the potential for unnecessarily waiting for completion of
+ * unrelated transactions, the caller can declare that only
+ * transactions of the current database are relevant at this
+ * stage.
+ */
+ if (db_specific)
+ {
+ /*
+ * If we must only keep track of transactions running in the current
+ * database, we need transaction info from exactly that database.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+
+ return;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ if (accessSharedCatalogsInDecoding)
+ accessSharedCatalogsInDecoding = false;
+ }
+
/* returns false if there's no point in performing cleanup just yet */
if (!SnapBuildFindSnapshot(builder, lsn, running))
return;
@@ -1155,6 +1199,16 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
else
SnapBuildSerialize(builder, lsn);
+ /*
+ * Database specific transaction info may exist to reach CONSISTENT state
+ * faster, however the code below makes no use of it. Moreover, such
+ * record might cause problems because the following normal (cluster-wide)
+ * record can have lower value of oldestRunningXid. In that case, let's
+ * wait with the cleanup for the next regular cluster-wide record.
+ */
+ if (OidIsValid(running->dbid))
+ return;
+
/*
* Update range of interesting xids based on the running xacts
* information. We don't increase ->xmax using it, because once we are in
@@ -1465,7 +1519,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 21a213a0ebf..a1f37e59dbc 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1756,7 +1756,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index f540bb6b23f..9299bcebbda 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2623,9 +2623,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2700,6 +2702,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2750,6 +2764,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2783,6 +2803,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..29af7733948 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,22 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that
+ * database. snapbuild.c can use such running xacts information for faster
+ * startup, but it still needs normal (cluster-wide) during the actual
+ * decoding - see standby_decode() and SnapBuildProcessRunningXacts() for
+ * details. Other processes (e.g. checkpointer) issue the cluster-wide records
+ * whether logical decoding is active or not.
+ *
+ * Please be careful about using this argument for other purposes. In
+ * particular, physical replication *must* ignore the database-specific
+ * records, exactly because they do not cover the whole cluster - see
+ * standby_redo().
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1333,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1377,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..c9a52277be1 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,13 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+
+/*
+ * Keep track of whether logical decoding in this backend promised not to
+ * access shared catalogs, as a safety check. Somewhat misplaced, but ...
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index a22a83a2f23..d02530a912a 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -92,7 +92,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- xl_running_xacts *running);
+ xl_running_xacts *running,
+ bool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index d718a5b542f..ec89c448220 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -47,7 +47,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 72+ messages in thread
* [PATCH] Introduce an option to make logical replication database specific.
@ 2026-04-06 08:49 Antonin Houska <[email protected]>
0 siblings, 0 replies; 72+ messages in thread
From: Antonin Houska @ 2026-04-06 08:49 UTC (permalink / raw)
By default, the logical decoding assumes access to shared catalogs, so the
snapshot builder needs to consider cluster-wide XIDs during startup. That in
turn means that, if any transaction is already running (and has XID assigned),
the snapshot builder needs to wait for its completion, as it does not know if
that transaction performed catalog changes earlier.
Possible problem with this concept is that if REPACK (CONCURRENTLY) is running
in some database, backends running the same command in other databases get
stuck until the first one has committed. Thus only as single backend in the
cluster can run REPACK (CONCURRENTLY) at any time. Likewise, REPACK
(CONCURRENTLY) can block walsenders starting on behalf of subscriptions
throughout the cluster.
This patch adds a new option to logical replication output plugin, to declare
that it does not use shared catalogs (i.e. catalogs that can be changed by
transactions running in other databases in the cluster). In that case, no
snapshot the backend will use during the decoding needs to contain information
about transactions running in other databases. Thus the snapshot builder only
needs to wait for completion of transactions in the current database.
Currently we only use this option in the REPACK background worker. It could
possibly be used in the plugin for logical replication too, however that would
need thorough analysis of that plugin.
The patch bumps WAL version number, due to a new field in xl_running_xacts.
---
contrib/pg_visibility/pg_visibility.c | 4 +-
doc/src/sgml/logicaldecoding.sgml | 4 ++
src/backend/access/index/genam.c | 8 +++
src/backend/access/rmgrdesc/standbydesc.c | 2 +
src/backend/access/transam/xlog.c | 2 +-
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/bgwriter.c | 2 +-
src/backend/replication/logical/decode.c | 16 +++++-
src/backend/replication/logical/logical.c | 3 +
src/backend/replication/logical/snapbuild.c | 64 ++++++++++++++++++++-
src/backend/replication/slot.c | 2 +-
src/backend/storage/ipc/procarray.c | 23 +++++++-
src/backend/storage/ipc/standby.c | 24 +++++++-
src/include/access/genam.h | 7 +++
src/include/access/xlog_internal.h | 2 +-
src/include/replication/output_plugin.h | 1 +
src/include/replication/snapbuild.h | 3 +-
src/include/storage/procarray.h | 2 +-
src/include/storage/standby.h | 3 +-
src/include/storage/standbydefs.h | 1 +
20 files changed, 157 insertions(+), 18 deletions(-)
diff --git a/contrib/pg_visibility/pg_visibility.c b/contrib/pg_visibility/pg_visibility.c
index dfab0b64cf5..d564bd2a00c 100644
--- a/contrib/pg_visibility/pg_visibility.c
+++ b/contrib/pg_visibility/pg_visibility.c
@@ -621,7 +621,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
else if (rel == NULL || rel->rd_rel->relisshared)
{
/* Shared relation: take into account all running xids */
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestRunningXid;
@@ -632,7 +632,7 @@ GetStrictOldestNonRemovableTransactionId(Relation rel)
* Normal relation: take into account xids running within the current
* database
*/
- runningTransactions = GetRunningTransactionData();
+ runningTransactions = GetRunningTransactionData(InvalidOid);
LWLockRelease(ProcArrayLock);
LWLockRelease(XidGenLock);
return runningTransactions->oldestDatabaseRunningXid;
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 6dc49108997..28089d1053c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -959,6 +959,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
</programlisting>
<literal>output_type</literal> has to either be set to
@@ -969,6 +970,9 @@ typedef struct OutputPluginOptions
also be called for changes made by heap rewrites during certain DDL
operations. These are of interest to plugins that handle DDL
replication, but they require special handling.
+ <literal>need_shared_catalogs</literal> can be set to false if you are
+ sure the plugin functions do not access shared system catalogs. It can
+ speed up creation of replication slots that use this plugin.
</para>
<para>
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1408989c568..44df2605068 100644
--- a/src/backend/access/index/genam.c
+++ b/src/backend/access/index/genam.c
@@ -394,6 +394,14 @@ systable_beginscan(Relation heapRelation,
SysScanDesc sysscan;
Relation irel;
+ /*
+ * If this backend promised that it won't access shared catalogs during
+ * logical decoding, this seems to be the right place to check.
+ */
+ Assert(!HistoricSnapshotActive() ||
+ accessSharedCatalogsInDecoding ||
+ !heapRelation->rd_rel->relisshared);
+
if (indexOK &&
!IgnoreSystemIndexes &&
!ReindexIsProcessingIndex(indexId))
diff --git a/src/backend/access/rmgrdesc/standbydesc.c b/src/backend/access/rmgrdesc/standbydesc.c
index 0a291354ae2..685d1bdb024 100644
--- a/src/backend/access/rmgrdesc/standbydesc.c
+++ b/src/backend/access/rmgrdesc/standbydesc.c
@@ -41,6 +41,8 @@ standby_desc_running_xacts(StringInfo buf, xl_running_xacts *xlrec)
for (i = 0; i < xlrec->subxcnt; i++)
appendStringInfo(buf, " %u", xlrec->xids[xlrec->xcnt + i]);
}
+
+ appendStringInfo(buf, "; dbid: %u", xlrec->dbid);
}
void
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index b82af9a85c0..3f08a832ca6 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7735,7 +7735,7 @@ CreateCheckPoint(int flags)
* recovery we don't need to write running xact data.
*/
if (!shutdown && XLogStandbyInfoActive())
- LogStandbySnapshot();
+ LogStandbySnapshot(InvalidOid);
START_CRIT_SECTION();
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 65bbaeda59c..0f5979691e6 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -245,7 +245,7 @@ pg_log_standby_snapshot(PG_FUNCTION_ARGS)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("pg_log_standby_snapshot() can only be used if \"wal_level\" >= \"replica\"")));
- recptr = LogStandbySnapshot();
+ recptr = LogStandbySnapshot(InvalidOid);
/*
* As a convenience, return the WAL location of the last inserted record
diff --git a/src/backend/postmaster/bgwriter.c b/src/backend/postmaster/bgwriter.c
index 1d8947774a9..a30de4262eb 100644
--- a/src/backend/postmaster/bgwriter.c
+++ b/src/backend/postmaster/bgwriter.c
@@ -289,7 +289,7 @@ BackgroundWriterMain(const void *startup_data, size_t startup_data_len)
if (now >= timeout &&
last_snapshot_lsn <= GetLastImportantRecPtr())
{
- last_snapshot_lsn = LogStandbySnapshot();
+ last_snapshot_lsn = LogStandbySnapshot(InvalidOid);
last_snapshot_ts = now;
}
}
diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
index 57aaef57c61..49a59605515 100644
--- a/src/backend/replication/logical/decode.c
+++ b/src/backend/replication/logical/decode.c
@@ -381,7 +381,15 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
{
xl_running_xacts *running = (xl_running_xacts *) XLogRecGetData(r);
- SnapBuildProcessRunningXacts(builder, buf->origptr, running);
+
+ /*
+ * If the plugin does not access shared catalogs, only keep
+ * track of transactions in the current database. This is
+ * currently the only use case for database-specific running
+ * xacts record.
+ */
+ SnapBuildProcessRunningXacts(builder, buf->origptr, running,
+ !ctx->options.need_shared_catalogs);
/*
* Abort all transactions that we keep track of, that are
@@ -391,8 +399,12 @@ standby_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
* all running transactions which includes prepared ones,
* while shutdown checkpoints just know that no non-prepared
* transactions are in progress.
+ *
+ * The database-specific records might work here too, but it's
+ * not their purpose.
*/
- ReorderBufferAbortOld(ctx->reorder, running->oldestRunningXid);
+ if (!OidIsValid(running->dbid))
+ ReorderBufferAbortOld(ctx->reorder, running->oldestRunningXid);
}
break;
case XLOG_STANDBY_LOCK:
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
index f20d0c542f3..8ceaf64d164 100644
--- a/src/backend/replication/logical/logical.c
+++ b/src/backend/replication/logical/logical.c
@@ -285,6 +285,9 @@ StartupDecodingContext(List *output_plugin_options,
ctx->write = do_write;
ctx->update_progress = update_progress;
+ /* Assume shared catalog access. The startup callback can change it. */
+ ctx->options.need_shared_catalogs = true;
+
ctx->output_plugin_options = output_plugin_options;
ctx->fast_forward = fast_forward;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index b4269a3b102..a10e8c0ca77 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -125,6 +125,7 @@
#include <sys/stat.h>
#include <unistd.h>
+#include "access/genam.h"
#include "access/heapam_xlog.h"
#include "access/transam.h"
#include "access/xact.h"
@@ -154,6 +155,14 @@
static ResourceOwner SavedResourceOwnerDuringExport = NULL;
static bool ExportInProgress = false;
+/*
+ * If a backend is going to do logical decoding and the output plugin does
+ * not need to access shared catalogs, setting this variable to false can make
+ * the decoding startup faster. In particular, the backend will not need to
+ * wait for completion of already running transactions in other databases.
+ */
+bool accessSharedCatalogsInDecoding = true;
+
/* ->committed and ->catchange manipulation */
static void SnapBuildPurgeOlderTxn(SnapBuild *builder);
@@ -170,7 +179,8 @@ static inline bool SnapBuildXidHasCatalogChanges(SnapBuild *builder, Transaction
uint32 xinfo);
/* xlog reading helper functions for SnapBuildProcessRunningXacts */
-static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running);
+static bool SnapBuildFindSnapshot(SnapBuild *builder, XLogRecPtr lsn,
+ xl_running_xacts *running);
static void SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff);
/* serialization functions */
@@ -226,6 +236,9 @@ AllocateSnapshotBuilder(ReorderBuffer *reorder,
MemoryContextSwitchTo(oldcontext);
+ /* The default is that shared catalog are used. */
+ accessSharedCatalogsInDecoding = true;
+
return builder;
}
@@ -244,6 +257,9 @@ FreeSnapshotBuilder(SnapBuild *builder)
builder->snapshot = NULL;
}
+ /* The default is that shared catalog are used. */
+ accessSharedCatalogsInDecoding = true;
+
/* other resources are deallocated via memory context reset */
MemoryContextDelete(context);
}
@@ -1136,7 +1152,8 @@ SnapBuildXidHasCatalogChanges(SnapBuild *builder, TransactionId xid,
* anymore.
*/
void
-SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
+SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running,
+ bool db_specific)
{
ReorderBufferTXN *txn;
TransactionId xmin;
@@ -1148,6 +1165,33 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
*/
if (builder->state < SNAPBUILD_CONSISTENT)
{
+ /*
+ * To reduce the potential for unnecessarily waiting for completion of
+ * unrelated transactions, the caller can declare that only
+ * transactions of the current database are relevant at this
+ * stage.
+ */
+ if (db_specific)
+ {
+ /*
+ * If we must only keep track of transactions running in the current
+ * database, we need transaction info from exactly that database.
+ */
+ if (running->dbid != MyDatabaseId)
+ {
+ LogStandbySnapshot(MyDatabaseId);
+
+ return;
+ }
+
+ /*
+ * We'd better be able to check during scan if the plugin does not
+ * lie.
+ */
+ if (accessSharedCatalogsInDecoding)
+ accessSharedCatalogsInDecoding = false;
+ }
+
/* returns false if there's no point in performing cleanup just yet */
if (!SnapBuildFindSnapshot(builder, lsn, running))
return;
@@ -1155,6 +1199,16 @@ SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xact
else
SnapBuildSerialize(builder, lsn);
+ /*
+ * Database specific transaction info may exist to reach CONSISTENT state
+ * faster, however the code below makes no use of it. Moreover, such
+ * record might cause problems because the following normal (cluster-wide)
+ * record can have lower value of oldestRunningXid. In that case, let's
+ * wait with the cleanup for the next regular cluster-wide record.
+ */
+ if (OidIsValid(running->dbid))
+ return;
+
/*
* Update range of interesting xids based on the running xacts
* information. We don't increase ->xmax using it, because once we are in
@@ -1465,7 +1519,11 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff)
*/
if (!RecoveryInProgress())
{
- LogStandbySnapshot();
+ /*
+ * If the last transaction info was about specific database, so needs
+ * to be the next one - at least until we're in the CONSISTENT state.
+ */
+ LogStandbySnapshot(running->dbid);
}
}
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 21a213a0ebf..a1f37e59dbc 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1756,7 +1756,7 @@ ReplicationSlotReserveWal(void)
XLogRecPtr flushptr;
/* make sure we have enough information to start */
- flushptr = LogStandbySnapshot();
+ flushptr = LogStandbySnapshot(InvalidOid);
/* and make sure it's fsynced to disk */
XLogFlush(flushptr);
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index f540bb6b23f..9299bcebbda 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2623,9 +2623,11 @@ ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc)
*
* Note that if any transaction has overflowed its cached subtransactions
* then there is no real need include any subtransactions.
+ *
+ * If 'dbid' is valid, only gather transactions running in that database.
*/
RunningTransactions
-GetRunningTransactionData(void)
+GetRunningTransactionData(Oid dbid)
{
/* result workspace */
static RunningTransactionsData CurrentRunningXactsData;
@@ -2700,6 +2702,18 @@ GetRunningTransactionData(void)
if (!TransactionIdIsValid(xid))
continue;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid))
+ {
+ int pgprocno = arrayP->pgprocnos[index];
+ PGPROC *proc = &allProcs[pgprocno];
+
+ if (proc->databaseId != dbid)
+ continue;
+ }
+
/*
* Be careful not to exclude any xids before calculating the values of
* oldestRunningXid and suboverflowed, since these are used to clean
@@ -2750,6 +2764,12 @@ GetRunningTransactionData(void)
PGPROC *proc = &allProcs[pgprocno];
int nsubxids;
+ /*
+ * Filter by database OID if requested.
+ */
+ if (OidIsValid(dbid) && proc->databaseId != dbid)
+ continue;
+
/*
* Save subtransaction XIDs. Other backends can't add or remove
* entries while we're holding XidGenLock.
@@ -2783,6 +2803,7 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ CurrentRunningXacts->dbid = dbid;
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_status = suboverflowed ? SUBXIDS_IN_SUBTRANS : SUBXIDS_IN_ARRAY;
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index de9092fdf5b..29af7733948 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1188,6 +1188,14 @@ standby_redo(XLogReaderState *record)
xl_running_xacts *xlrec = (xl_running_xacts *) XLogRecGetData(record);
RunningTransactionsData running;
+ /*
+ * Records issued for specific database are not suitable for physical
+ * replication because that affects the whole cluster. In particular,
+ * the list of XID is probably incomplete here.
+ */
+ if (OidIsValid(xlrec->dbid))
+ return;
+
running.xcnt = xlrec->xcnt;
running.subxcnt = xlrec->subxcnt;
running.subxid_status = xlrec->subxid_overflow ? SUBXIDS_MISSING : SUBXIDS_IN_ARRAY;
@@ -1277,11 +1285,22 @@ standby_redo(XLogReaderState *record)
* as there's no independent knob to just enable logical decoding. For
* details of how this is used, check snapbuild.c's introductory comment.
*
+ * If 'dbid' is valid, only gather transactions running in that
+ * database. snapbuild.c can use such running xacts information for faster
+ * startup, but it still needs normal (cluster-wide) during the actual
+ * decoding - see standby_decode() and SnapBuildProcessRunningXacts() for
+ * details. Other processes (e.g. checkpointer) issue the cluster-wide records
+ * whether logical decoding is active or not.
+ *
+ * Please be careful about using this argument for other purposes. In
+ * particular, physical replication *must* ignore the database-specific
+ * records, exactly because they do not cover the whole cluster - see
+ * standby_redo().
*
* Returns the RecPtr of the last inserted record.
*/
XLogRecPtr
-LogStandbySnapshot(void)
+LogStandbySnapshot(Oid dbid)
{
XLogRecPtr recptr;
RunningTransactions running;
@@ -1314,7 +1333,7 @@ LogStandbySnapshot(void)
* Log details of all in-progress transactions. This should be the last
* record we write, because standby will open up when it sees this.
*/
- running = GetRunningTransactionData();
+ running = GetRunningTransactionData(dbid);
/*
* GetRunningTransactionData() acquired ProcArrayLock, we must release it.
@@ -1358,6 +1377,7 @@ LogCurrentRunningXacts(RunningTransactions CurrRunningXacts)
xl_running_xacts xlrec;
XLogRecPtr recptr;
+ xlrec.dbid = CurrRunningXacts->dbid;
xlrec.xcnt = CurrRunningXacts->xcnt;
xlrec.subxcnt = CurrRunningXacts->subxcnt;
xlrec.subxid_overflow = (CurrRunningXacts->subxid_status != SUBXIDS_IN_ARRAY);
diff --git a/src/include/access/genam.h b/src/include/access/genam.h
index b69320a7fc8..c9a52277be1 100644
--- a/src/include/access/genam.h
+++ b/src/include/access/genam.h
@@ -136,6 +136,13 @@ typedef struct IndexOrderByDistance
bool isnull;
} IndexOrderByDistance;
+
+/*
+ * Keep track of whether logical decoding in this backend promised not to
+ * access shared catalogs, as a safety check. Somewhat misplaced, but ...
+ */
+extern bool accessSharedCatalogsInDecoding;
+
/*
* generalized index_ interface routines (in indexam.c)
*/
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index 10c18d39ff8..13ae3ad4fbb 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -32,7 +32,7 @@
/*
* Each page of XLOG file has a header like this:
*/
-#define XLOG_PAGE_MAGIC 0xD11E /* can be used as WAL version indicator */
+#define XLOG_PAGE_MAGIC 0xD11F /* can be used as WAL version indicator */
typedef struct XLogPageHeaderData
{
diff --git a/src/include/replication/output_plugin.h b/src/include/replication/output_plugin.h
index 842fcde67f9..917f3cff232 100644
--- a/src/include/replication/output_plugin.h
+++ b/src/include/replication/output_plugin.h
@@ -27,6 +27,7 @@ typedef struct OutputPluginOptions
{
OutputPluginOutputType output_type;
bool receive_rewrites;
+ bool need_shared_catalogs;
} OutputPluginOptions;
/*
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index a22a83a2f23..d02530a912a 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -92,7 +92,8 @@ extern void SnapBuildProcessNewCid(SnapBuild *builder, TransactionId xid,
XLogRecPtr lsn,
xl_heap_new_cid *xlrec);
extern void SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn,
- xl_running_xacts *running);
+ xl_running_xacts *running,
+ bool db_specific);
extern void SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn);
extern bool SnapBuildSnapshotExists(XLogRecPtr lsn);
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index d718a5b542f..ec89c448220 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -47,7 +47,7 @@ extern bool ProcArrayInstallImportedXmin(TransactionId xmin,
VirtualTransactionId *sourcevxid);
extern bool ProcArrayInstallRestoredXmin(TransactionId xmin, PGPROC *proc);
-extern RunningTransactions GetRunningTransactionData(void);
+extern RunningTransactions GetRunningTransactionData(Oid dbid);
extern bool TransactionIdIsInProgress(TransactionId xid);
extern TransactionId GetOldestNonRemovableTransactionId(Relation rel);
diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 6a314c693cd..8715c08e94f 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -126,6 +126,7 @@ typedef enum
typedef struct RunningTransactionsData
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
subxids_array_status subxid_status;
@@ -143,7 +144,7 @@ typedef RunningTransactionsData *RunningTransactions;
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
extern void LogAccessExclusiveLockPrepare(void);
-extern XLogRecPtr LogStandbySnapshot(void);
+extern XLogRecPtr LogStandbySnapshot(Oid dbid);
extern void LogStandbyInvalidations(int nmsgs, SharedInvalidationMessage *msgs,
bool relcacheInitFileInval);
diff --git a/src/include/storage/standbydefs.h b/src/include/storage/standbydefs.h
index 231d251fd51..e75b7078766 100644
--- a/src/include/storage/standbydefs.h
+++ b/src/include/storage/standbydefs.h
@@ -46,6 +46,7 @@ typedef struct xl_standby_locks
*/
typedef struct xl_running_xacts
{
+ Oid dbid; /* only track xacts in this database */
int xcnt; /* # of xact ids in xids[] */
int subxcnt; /* # of subxact ids in xids[] */
bool subxid_overflow; /* snapshot overflowed, subxids missing */
--
2.47.3
--=-=-=--
^ permalink raw reply [nested|flat] 72+ messages in thread
end of thread, other threads:[~2026-04-06 08:49 UTC | newest]
Thread overview: 72+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-01-26 09:54 [PATCH v4 4/5] Add documentation for ALTER SUBSCRIPTION...ADD/DROP PUBLICATION Japin Li <[email protected]>
2021-11-22 02:13 Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2021-11-22 19:29 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2021-11-23 01:07 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2021-11-23 05:49 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2021-11-24 01:01 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2021-11-24 01:32 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2021-11-30 19:52 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2021-12-10 21:48 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2021-12-15 20:26 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2021-12-17 06:46 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Masahiko Sawada <[email protected]>
2021-12-18 02:29 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2021-12-21 04:28 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Masahiko Sawada <[email protected]>
2021-12-21 05:35 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-02-26 01:52 Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-14 04:05 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-23 19:59 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-23 20:41 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Robert Haas <[email protected]>
2022-03-23 20:49 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-23 20:53 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Robert Haas <[email protected]>
2022-03-23 20:58 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-23 21:02 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Thomas Munro <[email protected]>
2022-03-23 22:28 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-24 17:20 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Robert Haas <[email protected]>
2022-03-24 19:28 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-24 20:21 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Robert Haas <[email protected]>
2022-03-24 21:40 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-28 03:24 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-29 17:03 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Robert Haas <[email protected]>
2022-03-29 18:58 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-30 03:08 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-30 06:10 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Justin Pryzby <[email protected]>
2022-03-30 07:01 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 00:50 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 02:00 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2022-03-31 02:37 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 02:51 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 03:28 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2022-03-31 03:35 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 04:04 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2022-03-31 04:11 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 04:24 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2022-03-31 04:20 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2022-03-31 04:29 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 04:44 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 04:59 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2022-03-31 16:37 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2022-03-31 16:58 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 17:11 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2022-03-31 17:16 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 17:12 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 17:50 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2022-03-31 18:19 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Peter Geoghegan <[email protected]>
2022-03-31 03:35 ` Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations Andres Freund <[email protected]>
2026-04-03 10:34 [PATCH v50 7/8] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-03 10:34 [PATCH v51 08/10] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-03 10:34 [PATCH v52 08/10] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-03 10:34 [PATCH v52 08/10] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-03 10:34 [PATCH v50 7/8] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-03 10:34 [PATCH v51 08/10] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-03 10:34 [PATCH] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-03 10:34 [PATCH] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-04 15:16 [PATCH] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-04 15:16 [PATCH v53 1/7] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-04 15:16 [PATCH] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-04 15:16 [PATCH v53 1/7] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-05 07:51 [PATCH] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-05 07:51 [PATCH v54 1/5] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-05 07:51 [PATCH] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-05 07:51 [PATCH v54 1/5] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-06 08:49 [PATCH] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
2026-04-06 08:49 [PATCH] Introduce an option to make logical replication database specific. Antonin Houska <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox