Stephan Szabo [EMAIL PROTECTED] writes:
I think all we need to do to implement things correctly is to consider a
previous event only if both xmin and cmin of the old tuple match the
current xact command IDs, rather than considering it on the basis of
xmin alone.
Are there any things that
On Wed, 24 Oct 2001, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I think all we need to do to implement things correctly is to consider a
previous event only if both xmin and cmin of the old tuple match the
current xact command IDs, rather than considering it on the basis of
Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I think all we need to do to implement things correctly is to consider a
previous event only if both xmin and cmin of the old tuple match the
current xact command IDs, rather than considering it on the basis of
xmin alone.
Are
On Wed, 24 Oct 2001, Tom Lane wrote:
The only reason we do this is to enforce the triggered data change
violation restriction of the spec. However, I think we've
misinterpreted the spec. The code prevents an RI referenced value from
being changed more than once in a transaction, but what
I have been looking at the way that deferred triggers slow down when the
same row is updated multiple times within a transaction. The problem
appears to be entirely due to calling deferredTriggerGetPreviousEvent()
to find the trigger list entry for the previous update of the row: we
do a linear
