Re: --enable-thread-safety bug

Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
>
>>Note this is your in application, not the server. Only your program
>>died. Ofcourse the transaction got aborted, since the client (you)
>>disconnected. There is no way for this to write to the server log,
>>since it may be one another machine...
>
>
> Right.  And note that if we don't have enough memory for the struct
> that was requested, we *certainly* don't have enough to do anything
> interesting.  We could try
>
>     fprintf(stderr, "out of memory\n");
>     exit(1);
>
> but even that I would give only about 50-50 odds of success; and more
> to the point, how is this any better for an application than a core
> dump?  It's still summary termination.
>
>
>>Do you create and destroy a lot of threads since it seems this memory
>>won't be freed?
>
>
> The OP's program isn't threaded at all, since he was apparently running
> with a non-threaded ecpg/libpq before.  This means that the proposal of
> looping till someone else frees memory is at least as silly as allowing
> the core dump to happen.
>
>             regards, tom lane
>
>
I guess the real question is why we are running out of memory when
this option is enabled.
Since my app doesn't use threads that points to a memory leak in the
ecpg library when enable thread
safety is turned on.


Steve