Skip site navigation (1) Skip section navigation (2)

Re: Compressing the AFTER TRIGGER queue

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Compressing the AFTER TRIGGER queue
Date: 2011-08-01 17:42:53
Message-ID: CAEZATCXk14N+rtefhkijHvbdZhAG=qmBj7qizn2xZ5khM=DMBQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 1 August 2011 18:36, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Aug 1, 2011 at 1:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>>> On 1 August 2011 17:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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

In response to

Responses

pgsql-hackers by date

Next:From: David FetterDate: 2011-08-01 17:46:20
Subject: Re: libedit memory stomp is apparently fixed in OS X Lion
Previous:From: Tom LaneDate: 2011-08-01 17:39:32
Subject: Re: One-Shot Plans

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group