Michael Meskes wrote:
On Sat, Mar 22, 2008 at 04:58:28PM -0400, Steve Clark wrote:
Not exactly sure what you are asking about - descriptors and auto
allocating.
So I guess you don't use either feature. :-)
The program processes about 80 packets a day, which can update
several tables
On Sat, Mar 22, 2008 at 04:58:28PM -0400, Steve Clark wrote:
> Not exactly sure what you are asking about - descriptors and auto
> allocating.
So I guess you don't use either feature. :-)
> The program processes about 80 packets a day, which can update
> several tables.
> It runs continou
Steve Clark <[EMAIL PROTECTED]> writes:
> I could do that - but in my situation I am not using threads so I
> really don't need --enable-thread-safety
> turned on. The freebsd ports maintainer for postgresql decided
> everybody should have it whether they
> needed it or not. I simply deleted the
Craig Ringer wrote:
Steve Clark wrote:
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.
It might be worth building ecpg with
Steve Clark wrote:
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.
It might be worth building ecpg with debug symbols then runni
Steve Clark wrote:
Michael Meskes wrote:
On Sat, Mar 22, 2008 at 12:51:30PM -0400, Steve Clark wrote:
My program had no threads - as I pointed out if I change the default
Makefile in the FreeBSD ports
system to not enable thread safety my programs runs just fine for days
on end. It appear
Michael Meskes wrote:
On Sat, Mar 22, 2008 at 12:51:30PM -0400, Steve Clark wrote:
My program had no threads - as I pointed out if I change the default
Makefile in the FreeBSD ports
system to not enable thread safety my programs runs just fine for days
on end. It appears to me
without any ki
On Sat, Mar 22, 2008 at 12:51:30PM -0400, Steve Clark wrote:
> My program had no threads - as I pointed out if I change the default
> Makefile in the FreeBSD ports
> system to not enable thread safety my programs runs just fine for days
> on end. It appears to me
> without any kind of close exa
On Sat, Mar 22, 2008 at 12:42:51PM -0400, Tom Lane wrote:
> > 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
Martijn van Oosterhout wrote:
On Sat, Mar 22, 2008 at 11:28:24AM -0400, Steve Clark wrote:
Retry - the malloc - maybe there is a memory leak when
--enable-thread-saftey is enabled,
send an out of memory message to the postgres log, abort the
transaction - I don't know I am
not a postgres devel
Tom Lane wrote:
Martijn van Oosterhout <[EMAIL PROTECTED]> 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 anothe
Martijn van Oosterhout <[EMAIL PROTECTED]> 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...
On Sat, Mar 22, 2008 at 11:28:24AM -0400, Steve Clark wrote:
> Retry - the malloc - maybe there is a memory leak when
> --enable-thread-saftey is enabled,
> send an out of memory message to the postgres log, abort the
> transaction - I don't know I am
> not a postgres developer so I don't know al
Tom Lane wrote:
Steve Clark <[EMAIL PROTECTED]> writes:
The return from malloc should be checked to make sure it succeeds -
right???
Probably, but what do you expect the code to do if it doesn't succeed?
This function seems not to have any defined error-return convention.
Steve Clark <[EMAIL PROTECTED]> writes:
> The return from malloc should be checked to make sure it succeeds -
> right???
Probably, but what do you expect the code to do if it doesn't succeed?
This function seems not to have any defined error-return convention.
regards, to
Hello List,
I am running 8.3.1 on FreeBSD 6.2 patch-7.
The ports for Freebsd turn on --enable-thread-safety during configure
of pg.
When running my app after some time I have been getting a core dump -
sig 11.
#0 0x28333b96 in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x28333b96 in memcp
16 matches
Mail list logo
