Tom Lane wrote:
>> It is odd. Actually, it looks like a bug to me. PQgetResult is the
>> behavior we were after, don't trigger the event if the creation
>> failed. Same thing occurs during a conn reset. Looks like PQclear
>> needs to check resultStatus before it triggers RESULTDESTROY events.
>
> If you did that, then you WOULD have a bug. Consider case where you
> successfully init two events, and the third one fails. You'll now
> change the result's status to ERROR. If you don't RESULTDESTROY
> then the first two events will leak whatever storage they allocated.
>
> The reason I suggested not being conditional about the init call was
> to reduce the probability of bugs of similar ilks associated with
> an event proc assuming that it could only get a DESTROY call for
> something it had seen CREATEd --- for example, if it were frobbing
> a reference count for some long-lived data, it could very easily
> screw up the reference count that way. I suppose that the risk of
> an earlier event proc failing means it has to cope with that case
> anyway, but I don't think it's a particularly good idea to have
> arbitrary asymmetries increasing the odds of a problem.
>
> regards, tom lane
>
>
Yeah. Good point. I fixed it to always fire events.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/