Antonin Houska <[email protected]>: > Although it could work, I think it'd be confusing to consider the transactions > being replayed as "current" from the point of view of the backend that > executes REPACK CONCURRENTLY.
Just realized SnapshotDirty is the thing that fits into the role - it respects not-yet committed transactions, giving enough information to wait for them. It is already used in a similar pattern in check_exclusion_or_unique_constraint and RelationFindReplTupleByIndex. So, it is easy to detect the case of the race you described previously and retry + there is no sense to hack around TransactionIdIsCurrentTransactionId. BWT, btree + SnapshotDirty has issue [0], but it is a different story and happens only with concurrent updates which are not present in the current scope. [0]: https://www.postgresql.org/message-id/flat/CADzfLwXGhH_qD6RGqPyEeKdmHgr-HpA-tASYdi5onP%2BRyP5TCw%40mail.gmail.com#77f6426ef2d282198f2d930d5334e3fa
