On Oct24, 2014, at 18:42 , Robert Haas <robertmh...@gmail.com> wrote: > I don't think you can count on being able to figure out all of the > recent lockers by looking at xmax; it can get overwritten. For > example, suppose transaction A locks the row and then commits. Then > transaction B comes along and again locks the row and commits. My > understanding is that B won't create a multi-xact since there's just > one locker; it'll just stomp on the previous xmax. > > Now, you could change that, but I suspect it would have pretty drastic > implications on systems that have both foreign keys and long-running > transactions.
Yes, we'd have to create multi-xids in some cases were we don't do that today. How big the effect would be, I honestly don't know. I guess it depends on how costly multi-xid creation is, compared to updating the parent row (to change its xmax) and updating or deleting child rows. My hope would be that it's cheap compared to that, but maybe that's not true, especially since multi-xids are xlog'ed nowadays. The only other option I see would be so teach the executor to check whether *any* snapshot between the transaction's snapshot and a current snapshot would see a different set of rows. Simply checking whether both the current snapshot and the transaction's snapshot see the same set isn't sufficient, per the counter-example in my other mail :-( An advantage of the latter is that I'd but the burden on the session that attempts to remove a parent row, instead of on the sessions which add or remove children. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
