On 1 August 2011 18:36, Robert Haas <[email protected]> wrote: > On Mon, Aug 1, 2011 at 1:31 PM, Tom Lane <[email protected]> wrote: >> Dean Rasheed <[email protected]> writes: >>> On 1 August 2011 17:49, Tom Lane <[email protected]> wrote: >>>> Ummm ... I only read the data structure comments, not the code, but I >>>> don't see where you store the second CTID for an update event? >> >>> Ah yes, I forgot to mention that bit. I'm using >>> &(tuple1.t_data->t_ctid) to get the second CTID from the old tuple. Is >>> that safe? >> >> Hmmmm ... not sure. It seems a bit scary, but on the other hand we >> should be able to assume that the updating subtransaction hasn't been >> rolled back (else surely we shouldn't be firing the trigger). So in >> principle it seems like the t_ctid link can't have been replaced. >> This will foreclose any ideas about collapsing t_ctid link chains, >> if anyone had it in mind to do that. > > Don't we already do that when pruning HOT chains? >
I thought that only happens after the transaction is committed, and old enough, whereas the trigger code only needs to follow the chain in the updating transaction. Regards, Dean -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
