From: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Patch that deals with that AtCommit_Portals encounters |
Date: | 2005-05-11 19:08:31 |
Message-ID: | thhal-0svBdA1+yyicCmX0AvF9AjGzG00YaBe@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
>
>>>This patch will ensure that the hash table iteration performed by
>>>AtCommit_Portals is restarted when a portal is deleted.
>>>
>>>
>
>
>
>>I have applied the following patch. I assume it is too risky for
>>backpatch to 8.0.X.
>>
>>
>
>I don't think it's appropriate in HEAD either --- it doesn't solve the
>problem, and it is an expensive way of not doing so :-(
>
>
It certanly solves my problem! And as for expensive? Why would it be? It
just restarts the iteration everytime something is removed. The only
thing that could make this patch consume CPU cycles is if there's a vast
amount of Portals in the iteration that are not candidates for removal.
I don't see that happen. Do you?
Regards,
Thomas Hallgren
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-05-11 19:25:39 | Re: [PATCHES] plperl and pltcl installcheck targets |
Previous Message | Tom Lane | 2005-05-11 19:00:54 | Re: Patch that deals with that AtCommit_Portals encounters |