Andres Freund <and...@2ndquadrant.com> writes: > On 2014-06-09 09:45:12 -0700, Kevin Grittner wrote: >> For purposes of predicate.c, if the "also deleted" activity might >> be rolled back without rolling back the insert, INSERT_IN_PROGRESS >> is the only correct value.
> That's basically the argument for the new behaviour. > But I am not sure, given predicate.c's coding, how > HEAPTUPLE_DELETE_IN_PROGRESS could cause problems. Could you elaborate, > since that's the contentious point with Tom? Since 'both in progress' > can only happen if xmin and xmax are the same toplevel xid and you > resolve subxids to toplevel xids I think it should currently be safe > either way? 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. 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? The reason this stuff is not too carefully spec'd is that when HTSV was written, there was no expectation that there was any correctness issue around which of these cases was returned. I wonder whether SSI should be using HTSV at all. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers