Tom Lane wrote:
Martijn van Oosterhout <kleptog@xxxxxxxxx> 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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
