Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit042b584

Browse files
committed
Revert changes to CONCURRENTLY that "sped up" Xmin advance
This reverts commitd9d0762 "VACUUM: ignore indexing operationswith CONCURRENTLY".These changes caused indexes created with the CONCURRENTLY option tomiss heap tuples that were HOT-updated and HOT-pruned during the indexcreation. Before these changes, HOT pruning would have been preventedby the Xmin of the transaction creating the index, but because thischange was precisely to allow the Xmin to move forward ignoring thatbackend, now other backends scanning the table can prune them. This isnot a problem for VACUUM (which requires a lock that conflicts with aCREATE INDEX CONCURRENTLY operation), but HOT-prune can definitelyoccur. In other words, Xmin advancement was sped up, but at the cost ofcorrupting the resulting index.Regrettably, this means that the new feature in PG14 that RIC/CIC onvery large tables no longer force VACUUM to retain very old tuples goesaway. We might try to implement it again in a later release, but fornow the risk of indexes missing tuples is too high and there's no easyfix.Backpatch to 14, where this change appeared.Reported-by: Peter Slavov <pet.slavov@gmail.com>Diagnosys-by: Andrey Borodin <x4mmm@yandex-team.ru>Diagnosys-by: Michael Paquier <michael@paquier.xyz>Diagnosys-by: Andres Freund <andres@anarazel.de>Discussion:https://postgr.es/m/17485-396609c6925b982d%40postgresql.org
1 parentc47a558 commit042b584

File tree

3 files changed

+7
-37
lines changed

3 files changed

+7
-37
lines changed

‎doc/src/sgml/ref/create_index.sgml

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -845,8 +845,6 @@ Indexes:
845845
Like any long-running transaction, <command>CREATE INDEX</command> on a
846846
table can affect which tuples can be removed by concurrent
847847
<command>VACUUM</command> on any other table.
848-
Excepted from this are operations with the <literal>CONCURRENTLY</literal>
849-
option for indexes that are not partial and do not index any expressions.
850848
</para>
851849

852850
<para>

‎doc/src/sgml/ref/reindex.sgml

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -470,8 +470,6 @@ Indexes:
470470
Like any long-running transaction, <command>REINDEX</command> on a table
471471
can affect which tuples can be removed by concurrent
472472
<command>VACUUM</command> on any other table.
473-
Excepted from this are operations with the <literal>CONCURRENTLY</literal>
474-
option for indexes that are not partial and do not index any expressions.
475473
</para>
476474

477475
<para>

‎src/backend/storage/ipc/procarray.c

Lines changed: 7 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -1667,13 +1667,7 @@ TransactionIdIsActive(TransactionId xid)
16671667
* relations that's not required, since only backends in my own database could
16681668
* ever see the tuples in them. Also, we can ignore concurrently running lazy
16691669
* VACUUMs because (a) they must be working on other tables, and (b) they
1670-
* don't need to do snapshot-based lookups. Similarly, for the non-catalog
1671-
* horizon, we can ignore CREATE INDEX CONCURRENTLY and REINDEX CONCURRENTLY
1672-
* when they are working on non-partial, non-expressional indexes, for the
1673-
* same reasons and because they can't run in transaction blocks. (They are
1674-
* not possible to ignore for catalogs, because CIC and RC do some catalog
1675-
* operations.) Do note that this means that CIC and RC must use a lock level
1676-
* that conflicts with VACUUM.
1670+
* don't need to do snapshot-based lookups.
16771671
*
16781672
* This also computes a horizon used to truncate pg_subtrans. For that
16791673
* backends in all databases have to be considered, and concurrently running
@@ -1723,6 +1717,9 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
17231717
boolin_recovery=RecoveryInProgress();
17241718
TransactionId*other_xids=ProcGlobal->xids;
17251719

1720+
/* inferred after ProcArrayLock is released */
1721+
h->catalog_oldest_nonremovable=InvalidTransactionId;
1722+
17261723
LWLockAcquire(ProcArrayLock,LW_SHARED);
17271724

17281725
h->latest_completed=ShmemVariableCache->latestCompletedXid;
@@ -1742,7 +1739,6 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
17421739

17431740
h->oldest_considered_running=initial;
17441741
h->shared_oldest_nonremovable=initial;
1745-
h->catalog_oldest_nonremovable=initial;
17461742
h->data_oldest_nonremovable=initial;
17471743

17481744
/*
@@ -1834,26 +1830,11 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
18341830
MyDatabaseId==InvalidOid||proc->databaseId==MyDatabaseId||
18351831
proc->databaseId==0)/* always include WalSender */
18361832
{
1837-
/*
1838-
* We can ignore this backend if it's running CREATE INDEX
1839-
* CONCURRENTLY or REINDEX CONCURRENTLY on a "safe" index -- but
1840-
* only on vacuums of user-defined tables.
1841-
*/
1842-
if (!(statusFlags&PROC_IN_SAFE_IC))
1843-
h->data_oldest_nonremovable=
1844-
TransactionIdOlder(h->data_oldest_nonremovable,xmin);
1845-
1846-
/* Catalog tables need to consider all backends in this db */
1847-
h->catalog_oldest_nonremovable=
1848-
TransactionIdOlder(h->catalog_oldest_nonremovable,xmin);
1849-
1833+
h->data_oldest_nonremovable=
1834+
TransactionIdOlder(h->data_oldest_nonremovable,xmin);
18501835
}
18511836
}
18521837

1853-
/* catalog horizon should never be later than data */
1854-
Assert(TransactionIdPrecedesOrEquals(h->catalog_oldest_nonremovable,
1855-
h->data_oldest_nonremovable));
1856-
18571838
/*
18581839
* If in recovery fetch oldest xid in KnownAssignedXids, will be applied
18591840
* after lock is released.
@@ -1875,8 +1856,6 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
18751856
TransactionIdOlder(h->shared_oldest_nonremovable,kaxmin);
18761857
h->data_oldest_nonremovable=
18771858
TransactionIdOlder(h->data_oldest_nonremovable,kaxmin);
1878-
h->catalog_oldest_nonremovable=
1879-
TransactionIdOlder(h->catalog_oldest_nonremovable,kaxmin);
18801859
/* temp relations cannot be accessed in recovery */
18811860
}
18821861
else
@@ -1903,9 +1882,6 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
19031882
h->data_oldest_nonremovable=
19041883
TransactionIdRetreatedBy(h->data_oldest_nonremovable,
19051884
vacuum_defer_cleanup_age);
1906-
h->catalog_oldest_nonremovable=
1907-
TransactionIdRetreatedBy(h->catalog_oldest_nonremovable,
1908-
vacuum_defer_cleanup_age);
19091885
/* defer doesn't apply to temp relations */
19101886
}
19111887

@@ -1928,9 +1904,7 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
19281904
h->shared_oldest_nonremovable=
19291905
TransactionIdOlder(h->shared_oldest_nonremovable,
19301906
h->slot_catalog_xmin);
1931-
h->catalog_oldest_nonremovable=
1932-
TransactionIdOlder(h->catalog_oldest_nonremovable,
1933-
h->slot_xmin);
1907+
h->catalog_oldest_nonremovable=h->data_oldest_nonremovable;
19341908
h->catalog_oldest_nonremovable=
19351909
TransactionIdOlder(h->catalog_oldest_nonremovable,
19361910
h->slot_catalog_xmin);

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp