Re: Patch that deals with that AtCommit_Portals encounters

Tom Lane wrote:

>Neil Conway <neilc(at)samurai(dot)com> writes:
>
>
>>Thomas Hallgren wrote:
>>
>>
>>>This patch will ensure that the hash table iteration performed by
>>>AtCommit_Portals is restarted when a portal is deleted.
>>>
>>>
>
>
>
>>I'll apply this to HEAD within 24 hours, barring any objections.
>>
>>
>
>I don't believe that this actually fixes anything.
>
>In particular, if portal A actually tries to reference portal B during
>A's deletion, there is only a 50% chance that this prevents problems.
>And since the hash table is traversed in hashcode order, you can't
>really imagine that you know which one will be deleted first.
>
>
Tom,
as I explained to you in an earlier mail exchange, I indeed do cover the
cases where B would be deleted before A by intercepting a callback in
the portal. So this patch really solve a problem, at least for me. It it
would be even better if accompanied by a patch allowing a
destroy-callback to be (properly) registered with a Portal.

I asked you if that would be something to consider but got no reply. If
you do think that's a good idea, please approve this patch for now and
I'll deliver another for the callbacks shortly.

>I think a correct fix would involve suppressing that reference in the
>first place, rather than making ad-hoc alterations in the traversal
>behavior.
>
>
I'm not sure what you mean. Earlier you rejected my bug-report on the
iterator because you it was the callers responsability to deal with it
(hence this patch). Are you now suggesting that we fix that bug instead?

Regards,
Thomas Hallgren