Tom Lane wrote:

Neil Conway <[EMAIL PROTECTED]> 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.

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

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?

Thomas Hallgren

---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to