Re: BUG #6200: standby bad memory allocations on SELECT - Mailing list pgsql-bugs

All right, so we were able to get a full bt of the alloc error on a test
system.  Also, since we have a lot of emails going around on this - I
wanted to make it clear that we're seeing *two* production errors, which
may or may not be related.  (The OP for bug #6200 also sees both issues.)
One is a segfault, our emails over the weekend were for that, and we don't
have a complete bt for that (we're going to install our own build of
postrges to get that.)

The second error is an invalid memory alloc error that we're getting ~2
dozen times per day in production.  The bt for this alloc error is below.

Please note also that this is from a version of postgres which we modified
to panic when we hit the invalid memory alloc line.  So, postgres won't
actually segfault here, it just outputs an error and continues.  We
modified this to panic so we could catch a bt, and it looks like we did get
one :)

Anyway, here goes...

#0  0x0000003a83e30265 in raise () from /lib64/libc.so.6
#1  0x0000003a83e31d10 in abort () from /lib64/libc.so.6
#2  0x00000000007cb84e in errfinish (dummy=0) at elog.c:523
#3  0x00000000007cd951 in elog_finish (elevel=22, fmt=0x95cdf0 "invalid
memory alloc request size %lu") at elog.c:1202
#4  0x00000000007f115c in MemoryContextAlloc (context=0x17b581d0,
size=18446744073709551613) at mcxt.c:516
#5  0x0000000000771a46 in text_to_cstring (t=0x17b23608) at varlena.c:139
#6  0x0000000000770747 in varcharout (fcinfo=0x7fffd44854e0) at
varchar.c:515
#7  0x00000000007d3ea8 in FunctionCall1Coll (flinfo=0x17b7b5c0,
collation=0, arg1=397555208) at fmgr.c:1293
#8  0x00000000007d5562 in OutputFunctionCall (flinfo=0x17b7b5c0,
val=397555208) at fmgr.c:1946
#9  0x000000000045a4a1 in printtup (slot=0x17d27b80, self=0x17a9cf00) at
printtup.c:338
#10 0x00000000005bab14 in ExecutePlan (estate=0x17d27a70,
planstate=0x17d27c10, operation=CMD_SELECT, sendTuples=1 '\001',
    numberTuples=0, direction=ForwardScanDirection, dest=0x17a9cf00) at
execMain.c:1464
#11 0x00000000005b9205 in standard_ExecutorRun (queryDesc=0x17b87918,
direction=ForwardScanDirection, count=0) at execMain.c:313
#12 0x00000000005b9100 in ExecutorRun (queryDesc=0x17b87918,
direction=ForwardScanDirection, count=0) at execMain.c:261
#13 0x00000000006d3b88 in PortalRunSelect (portal=0x17ae2c30, forward=1
'\001', count=0, dest=0x17a9cf00) at pquery.c:943
#14 0x00000000006d3849 in PortalRun (portal=0x17ae2c30,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x17a9cf00,
    altdest=0x17a9cf00, completionTag=0x7fffd4485cd0 "") at pquery.c:787
#15 0x00000000006cf62d in exec_execute_message (portal_name=0x17a9caf0 "",
max_rows=9223372036854775807) at postgres.c:1963
#16 0x00000000006d1e81 in PostgresMain (argc=2, argv=0x179bdaa8,
username=0x179bd8c0 "datamover") at postgres.c:3983
#17 0x0000000000686256 in BackendRun (port=0x179e2350) at postmaster.c:3601
#18 0x000000000068593f in BackendStartup (port=0x179e2350) at
postmaster.c:3286
#19 0x0000000000682af2 in ServerLoop () at postmaster.c:1455
#20 0x0000000000682298 in PostmasterMain (argc=3, argv=0x179bbc80) at
postmaster.c:1116
#21 0x00000000005fe007 in main (argc=3, argv=0x179bbc80) at main.c:199