On Mon, Oct 07, 2013 at 12:26:37PM +0300, Heikki Linnakangas wrote: > When updating a tuple, CheckTargetForConflictsIn() only marks a > conflict if the transaction holding the predicate lock overlapped > with the updating transaction.
Ah, this is the bit I was forgetting. (I really ought to have remembered that, but it's been a while...) I think it's possible, then, to construct a scenario where a slot is reused before predicate locks on the old tuple are eligible for cleanup -- but those locks will never cause a conflict. So I agree: it's correct to just remove the xmin from the key unconditionally. And this is also true: > And if there's a hole in that thinking I can't see right now, > the worst that will happen is some unnecessary conflicts, ie. it's > still correct. It surely can't be worse than upgrading the lock to a > page-level lock, which would also create unnecessary conflicts. Dan -- Dan R. K. Ports UW CSE http://drkp.net/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
