On Oct24, 2014, at 18:42 , Robert Haas <robertmhaas@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