Tom Lane wrote:
> pgsql <pgsql@lavabit.com> writes:
>> Tom Lane wrote:
>>> Um, that's not too helpful, we want to see the string it's pointing at.
>
>> Sorry about that. All statements are calling one of two pl/pgsql
>> functions. While that information already helps me a lot, it'll take me
>> a while to step through the code. Those functions are outer wrappers
>> calling many other procedures.
>
> Well, the stack trace you showed previously indicates that the crash is
> happening in the outermost plpgsql function (ie, one called directly
> from a client SQL command). However it's certainly true that the crash
> might be a consequence of something that had been done a bit earlier in
> another function called by this one.
Sorry for the late reply. The only DDL performed is indeed in the outer
function and it's a TRUNCATE, immediately followed by an INSERT SELECT
to repopulate the truncated table.
As mentioned, I build 8.3.10 from source using --enable-debug
--enable-cassert. I had issues with this version causing protection
faults. Also the backtrace I got from that still doesn't include line
numbers and arguments. So I assume I missed something important when
doing the build?
postgres[7172] general protection rip:44abd8 rsp:7fff9195a060 error:0
Core was generated by `postgres: <user> <database> <client_ip>(51'.
Program terminated with signal 11, Segmentation fault.
[New process 7172]
#0 0x000000000044abd8 in index_form_tuple ()
(gdb) bt
#0 0x000000000044abd8 in index_form_tuple ()
#1 0x0000000000000001 in ?? ()
#2 0x000000000153d968 in ?? ()
#3 0x0000000000670634 in tuplesort_performsort ()
#4 0x0000000000000000 in ?? ()
I decided to strip the debug options (as they somehow seem to cause
issue on that system) and instead apply the patch you pointed out. No
crashes since then anymore.
Thanks for your support.
