On Sat, Mar 25, 2023 at 6:25 PM Peter Geoghegan <p...@bowt.ie> wrote: > On Fri, Mar 24, 2023 at 8:13 AM Robert Haas <rh...@postgresql.org> wrote: > > If we're checking xmin and find that it is invalid (i.e. 0) just > > report that as corruption, similar to what's already done in the > > three cases that seem correct. If we're checking xmax and find > > that's invalid, that's fine: it just means that the tuple hasn't > > been updated or deleted. > > What about aborted speculative insertions? See > heap_abort_speculative(), which directly sets the speculatively > inserted heap tuple's xmin to InvalidTransactionId/zero.
Oh, dear. I didn't know about that case. > It probably does make sense to keep something close to this check -- > it just needs to account for speculative insertions to avoid false > positive reports of corruption. We could perform cross-checks against > a tuple whose xmin is InvalidTransactionId/zero to verify that it > really is from an aborted speculative insertion, to the extent that > that's possible. For example, such a tuple can't be a heap-only tuple, > and it can't have any xmax value other than InvalidTransactionId/zero. Since this was back-patched, I think it's probably better to just remove the error. We can introduce new validation if we want, but that should probably be master-only. -- Robert Haas EDB: http://www.enterprisedb.com
