daveg wrote:
> On Fri, Apr 11, 2008 at 06:25:53PM -0400, Tom Lane wrote:
>> Andrew Chernow <ac@esilo.com> writes:
>>> A more graceful solution would be to print something to stderr and then
>>> exit.
>> stderr doesn't exist, or point to a useful place, in many environments.
>> And a forced exit() is no better than a crash for most purposes.
>>
>>> I don't think libpq should core dump an app by choice.
>> The case that we are talking about is a bug, or would be a bug if it
>> could happen (the fact that we've gotten along happily with no similar
>> test in the existing code shows that it can't). Many forms of bug can
>> result in core dumps; it's foolish to try to prevent them all. And
>> bloating one line of code into five or more lines to defend against
>> can't-happen cases is a good way to end up with unreadable,
>> unmaintainable software.
>>
>> regards, tom lane
>
> +1
>
> -dg
okay.
BTW, my real interest here is the libpq hooks patch requires a
lock/unlock for every conn-create, conn-destroy, result-create,
result-destroy. Currently, it looks like only the ssl stuff uses
mutexes. Adding more mutex use is a good case for a more optimized
approach on windows.
andrew
