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
> >> xmi
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
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 th
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 w
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 s
