I'm using 7.2.3 on an SMP MIPS Linux kernel 2.4.17, libc 2.2.3
My organization has mocked around with the kernel (memory manager, etc) and
as such I'm leaving much room for "its our bad" ....I'll work on having
another target
to compile with --enable-debug and cassert...
Again, I need to make sure that my Async Query is not amplifying the
problem....
So currently I need to keep a table within a range (low-water and
hi-water mark).
So I have implemented a "Async and Interleaved Purge". When I hit the
hi-water-mark,
I do the Async Purge of 2000 rows. At mid-water mark, I do the
vacuum-ing by sending
an async query. Again I close connections and move on.....hoping that
the backend
will thru away anything it had to say after completing the task...
Thanks for the help...
Tom Lane wrote:
>Medi Montaseri <medi.montaseri@intransa.com> writes:
>
>
>>Has anyone experienced a pfree() related core dump in 7.2.3.
>>Here is my gdb backtrace
>>
>>
>
>
>
>>(gdb) bt
>>#0 0x005dbb5c in pfree ()
>>#1 0x004208c0 in heap_freetuple ()
>>#2 0x004a8390 in acquire_sample_rows ()
>>#3 0x004a75c8 in analyze_rel ()
>>#4 0x0049f690 in vacuum ()
>>#5 0x005585d8 in ProcessUtility ()
>>#6 0x00553c78 in pg_exec_query_string ()
>>
>>
>
>Hmm ... my first thought is something overrunning its memory allocation
>and clobbering the mem manager's header for an adjacent palloc chunk.
>However, it's impossible to guess what, with only this much info.
>
>Could you rebuild the backend with --enable-debug --enable-cassert added
>to the configure arguments, and reproduce the test case to get a more
>informative backtrace?
>
>Also, what platform is this on?
>
>
>
>>FYI, I'm using the Async Query for my vacuum as shown below and I'm
>>not doing the PQgetResult(), so I'm hoping that closing the connection will
>>tear down the backend after finishing the vacuum...
>>
>>
>
>I doubt this is affected by what you're doing on the client side.
>
> regards, tom lane
>
>
