Tom Lane <t...@sss.pgh.pa.us> wrote: > Assuming that Kevin's describing his needs correctly, we could resolve > this by inventing HEAPTUPLE_INSERT_AND_DELETE_IN_PROGRESS. VACUUM could > assume that that's a probably-dead tuple, while SSI could do something > different.
That could work. On the other hand, the old code, where such a transaction showed as HEAPTUPLE_DELETE_IN_PROGRESS, might still work for predicate.c as long as it's clear that this return code sometimes means "insert and delete are both in progress and the insert might commit without committing the delete". Those conditions could be identified within predicate.c; although it seems like that would involve duplicating some work which was already in HTSV, with the usual costs and risks of duplicate code. > I'm not sure if it's worth special-casing xmin == xmax, > where the tuple is guaranteed to never be of interest to any other > transaction? That could be checked in predicate.c. I see no reason to create a separate return code for it if it's not of interest for other callers. It could even be left as a later optimization, since a false positive serialization failure doesn't compromise correctness, but it seems like it is probably easy enough to cover to just do so now. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
