]> granicus.if.org Git - postgresql/commit
Do not select new object OIDs that match recently-dead entries.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 11 Apr 2018 21:41:09 +0000 (17:41 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 11 Apr 2018 21:41:22 +0000 (17:41 -0400)
commit0408e1ed599b06d9bca2927a50a4be52c9e74bb9
tree24111a9955711f2345b5821ba3b380d47fb3242c
parent811969b218ac2e8030dfbbb05873344967461618
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
src/backend/access/heap/tuptoaster.c
src/backend/catalog/catalog.c