Re: --enable-thread-safety bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Steve Clark <sclark(at)netwolves(dot)com>, pgsql <pgsql-general(at)postgresql(dot)org>
Subject: Re: --enable-thread-safety bug
Date: 2008-03-22 16:42:51
Message-ID: 29915.1206204171@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Martijn van Oosterhout <kleptog(at)svana(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steve Clark 2008-03-22 16:51:30 Re: --enable-thread-safety bug
Previous Message Martijn van Oosterhout 2008-03-22 16:27:38 Re: --enable-thread-safety bug