Skip to content

Commit 8bba10f

Browse files
committed
Do not select new object OIDs that match recently-dead entries.
When selecting a new OID, we take care to avoid picking one that's already in use in the target table, so as not to create duplicates after the OID counter has wrapped around. However, up to now we used SnapshotDirty when scanning for pre-existing entries. That ignores committed-dead rows, so that we could select an OID matching a deleted-but-not-yet-vacuumed row. While that mostly worked, it has two problems: * If recently deleted, the dead row might still be visible to MVCC snapshots, creating a risk for duplicate OIDs when examining the catalogs within our own transaction. Such duplication couldn't be visible outside the object-creating transaction, though, and we've heard few if any field reports corresponding to such a symptom. * When selecting a TOAST OID, deleted toast rows definitely *are* visible to SnapshotToast, and will remain so until vacuumed away. This leads to a conflict that will manifest in errors like "unexpected chunk number 0 (expected 1) for toast value nnnnn". We've been seeing reports of such errors from the field for years, but the cause was unclear before. The fix is simple: just use SnapshotAny to search for conflicting rows. This results in a slightly longer window before object OIDs can be recycled, but that seems unlikely to create any large problems. Pavan Deolasee Discussion: https://postgr.es/m/CABOikdOgWT2hHkYG3Wwo2cyZJq2zfs1FH0FgX-=h4OLosXHf9w@mail.gmail.com
1 parent 74dc05e commit 8bba10f

File tree

2 files changed

+12
-11
lines changed

2 files changed

+12
-11
lines changed

src/backend/access/heap/tuptoaster.c

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1725,7 +1725,9 @@ toast_delete_datum(Relation rel, Datum value, bool is_speculative)
17251725
/* ----------
17261726
* toastrel_valueid_exists -
17271727
*
1728-
* Test whether a toast value with the given ID exists in the toast relation
1728+
* Test whether a toast value with the given ID exists in the toast relation.
1729+
* For safety, we consider a value to exist if there are either live or dead
1730+
* toast rows with that ID; see notes for GetNewOid().
17291731
* ----------
17301732
*/
17311733
static bool
@@ -1737,7 +1739,6 @@ toastrel_valueid_exists(Relation toastrel, Oid valueid)
17371739
int num_indexes;
17381740
int validIndex;
17391741
Relation *toastidxs;
1740-
SnapshotData SnapshotToast;
17411742

17421743
/* Fetch a valid index relation */
17431744
validIndex = toast_open_indexes(toastrel,
@@ -1756,10 +1757,9 @@ toastrel_valueid_exists(Relation toastrel, Oid valueid)
17561757
/*
17571758
* Is there any such chunk?
17581759
*/
1759-
init_toast_snapshot(&SnapshotToast);
17601760
toastscan = systable_beginscan(toastrel,
17611761
RelationGetRelid(toastidxs[validIndex]),
1762-
true, &SnapshotToast, 1, &toastkey);
1762+
true, SnapshotAny, 1, &toastkey);
17631763

17641764
if (systable_getnext(toastscan) != NULL)
17651765
result = true;

src/backend/catalog/catalog.c

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -278,8 +278,12 @@ IsSharedRelation(Oid relationId)
278278
* managed to cycle through 2^32 OIDs and generate the same OID before we
279279
* finish inserting our row. This seems unlikely to be a problem. Note
280280
* that if we had to *commit* the row to end the race condition, the risk
281-
* would be rather higher; therefore we use SnapshotDirty in the test,
282-
* so that we will see uncommitted rows.
281+
* would be rather higher; therefore we use SnapshotAny in the test, so that
282+
* we will see uncommitted rows. (We used to use SnapshotDirty, but that has
283+
* the disadvantage that it ignores recently-deleted rows, creating a risk
284+
* of transient conflicts for as long as our own MVCC snapshots think a
285+
* recently-deleted row is live. The risk is far higher when selecting TOAST
286+
* OIDs, because SnapshotToast considers dead rows as active indefinitely.)
283287
*/
284288
Oid
285289
GetNewOid(Relation relation)
@@ -332,7 +336,6 @@ Oid
332336
GetNewOidWithIndex(Relation relation, Oid indexId, AttrNumber oidcolumn)
333337
{
334338
Oid newOid;
335-
SnapshotData SnapshotDirty;
336339
SysScanDesc scan;
337340
ScanKeyData key;
338341
bool collides;
@@ -345,8 +348,6 @@ GetNewOidWithIndex(Relation relation, Oid indexId, AttrNumber oidcolumn)
345348
*/
346349
Assert(!IsBinaryUpgrade || RelationGetRelid(relation) != TypeRelationId);
347350

348-
InitDirtySnapshot(SnapshotDirty);
349-
350351
/* Generate new OIDs until we find one not in the table */
351352
do
352353
{
@@ -359,9 +360,9 @@ GetNewOidWithIndex(Relation relation, Oid indexId, AttrNumber oidcolumn)
359360
BTEqualStrategyNumber, F_OIDEQ,
360361
ObjectIdGetDatum(newOid));
361362

362-
/* see notes above about using SnapshotDirty */
363+
/* see notes above about using SnapshotAny */
363364
scan = systable_beginscan(relation, indexId, true,
364-
&SnapshotDirty, 1, &key);
365+
SnapshotAny, 1, &key);
365366

366367
collides = HeapTupleIsValid(systable_getnext(scan));
367368

0 commit comments

Comments
 (0)