Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running

Поиск
Список
Период
Сортировка
От Frank van Vugt
Тема Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
Дата
Msg-id 200412030103.43696.ftm.van.vugt@foxi.nl
обсуждение исходный текст
Ответ на Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
> > Here's what's going on when the memory alloc problem occurs:

> AFAICS this can only be explained as a memory stomp on the static data
> structures SerializableSnapshotData or LatestSnapshotData.  That seems a
> tad improbable.  I wonder if what you have is a build problem.  Have you
> tried a full "make distclean", configure, rebuild from scratch?

Yep, I always do a distclean when changing configuration options, I've been
bitten before ;)

Mind you, I am using the earlier discussed patch to avoid the glibc bug :

******************************************************
$> more oracle_compat.diff
--- src/backend/utils/adt/oracle_compat.c_orig  Mon Nov 29 12:25:20 2004
+++ src/backend/utils/adt/oracle_compat.c       Mon Nov 29 12:26:49 2004
@@ -43,7 +43,7 @@
  * We assume if we have these two functions, we have their friends too, and
  * can use the wide-character method.
  */
-#if defined(HAVE_WCSTOMBS) && defined(HAVE_TOWLOWER)
+#if defined(HAVE_WCSTOMBS) && defined(HAVE_TOWLOWER) && FALSE
 #define USE_WIDE_UPPER_LOWER
 #endif
******************************************************

I could reproduce this case tomorrow and inspect some variables or call
abort() if you think that could be of any help?




As far as the other problem is concerned, I just finished the first half of
the conversion on a different machine that was build with assertions enabled
and saw a number of reports like the ones below. What's causing these?

I'll start the second half in a minute, which should reproduce the TRAP pretty
soon. Will post a backtrace of that asap as well.


Program received signal SIGUSR1, User defined signal 1.
0x40109ac1 in kill () from /lib/libc.so.6
(gdb) where
#0  0x40109ac1 in kill () from /lib/libc.so.6
#1  0x0818e9e1 in SendPostmasterSignal (reason=PMSIGNAL_PASSWORD_CHANGE) at
pmsignal.c:69
#2  0x081906a8 in SIInsertDataEntry (segP=0xdbd, data=0x83e4af8) at
sinvaladt.c:229
#3  0x0818f7e2 in SendSharedInvalidMessage (msg=0x83e4af8) at sinval.c:122
#4  0x081ffcd8 in ProcessInvalidationMessages (hdr=0x83dd6a4, func=0x818f7c0
<SendSharedInvalidMessage>) at inval.c:343
#5  0x082001d6 in AtEOXact_Inval (isCommit=1 '\001') at inval.c:674
#6  0x080a2548 in CommitTransaction () at xact.c:1543
#7  0x080a2af5 in CommitTransactionCommand () at xact.c:1938
#8  0x0819caef in finish_xact_command () at postgres.c:1843
#9  0x0819b795 in exec_simple_query (query_string=0x834ee8c "drop table
lijst45_table") at postgres.c:965
#10 0x0819dce0 in PostgresMain (argc=4, argv=0x8308b0c, username=0x8308adc
"megaconv") at postgres.c:2986
#11 0x08171f31 in BackendRun (port=0x83177f0) at postmaster.c:2817
#12 0x08171991 in BackendStartup (port=0x83177f0) at postmaster.c:2453
#13 0x0816ff6f in ServerLoop () at postmaster.c:1198
#14 0x0816f4a3 in PostmasterMain (argc=3, argv=0x8307788) at postmaster.c:917
#15 0x0813d22d in main (argc=3, argv=0x8307788) at main.c:268
#16 0x400f5d06 in __libc_start_main () from /lib/libc.so.6

Program received signal SIGUSR1, User defined signal 1.
0x40109ac1 in kill () from /lib/libc.so.6
(gdb) where
#0  0x40109ac1 in kill () from /lib/libc.so.6
#1  0x0818e9e1 in SendPostmasterSignal (reason=PMSIGNAL_PASSWORD_CHANGE) at
pmsignal.c:69
#2  0x081906a8 in SIInsertDataEntry (segP=0xdbd, data=0x8408e20) at
sinvaladt.c:229
#3  0x0818f7e2 in SendSharedInvalidMessage (msg=0x8408e20) at sinval.c:122
#4  0x081ffcd8 in ProcessInvalidationMessages (hdr=0x8407844, func=0x818f7c0
<SendSharedInvalidMessage>) at inval.c:343
#5  0x082001d6 in AtEOXact_Inval (isCommit=1 '\001') at inval.c:674
#6  0x080a2548 in CommitTransaction () at xact.c:1543
#7  0x080a2af5 in CommitTransactionCommand () at xact.c:1938
#8  0x0819caef in finish_xact_command () at postgres.c:1843
#9  0x0819b795 in exec_simple_query (
    query_string=0x834f0a4 "create table lijst55_table(invoice_id
int,serial_id int,payment_cond text,old_debtor_id text,debtor_descr
text,korting numeric,magazijncode int,pakbon_nr text,totaal_bruto
numeric,totaal_netto numeric"...) at postgres.c:965
#10 0x0819dce0 in PostgresMain (argc=4, argv=0x8308b0c, username=0x8308adc
"megaconv") at postgres.c:2986
#11 0x08171f31 in BackendRun (port=0x83177f0) at postmaster.c:2817
#12 0x08171991 in BackendStartup (port=0x83177f0) at postmaster.c:2453
#13 0x0816ff6f in ServerLoop () at postmaster.c:1198
#14 0x0816f4a3 in PostmasterMain (argc=3, argv=0x8307788) at postmaster.c:917
#15 0x0813d22d in main (argc=3, argv=0x8307788) at main.c:268
#16 0x400f5d06 in __libc_start_main () from /lib/libc.so.6
(gdb)

Program received signal SIGUSR1, User defined signal 1.
0x40109ac1 in kill () from /lib/libc.so.6
(gdb) where
#0  0x40109ac1 in kill () from /lib/libc.so.6
#1  0x0818e9e1 in SendPostmasterSignal (reason=PMSIGNAL_PASSWORD_CHANGE) at
pmsignal.c:69
#2  0x081906a8 in SIInsertDataEntry (segP=0xdbd, data=0x842bb40) at
sinvaladt.c:229
#3  0x0818f7e2 in SendSharedInvalidMessage (msg=0x842bb40) at sinval.c:122
#4  0x081ffcd8 in ProcessInvalidationMessages (hdr=0x842514c, func=0x818f7c0
<SendSharedInvalidMessage>) at inval.c:343
#5  0x082001d6 in AtEOXact_Inval (isCommit=1 '\001') at inval.c:674
#6  0x080a2548 in CommitTransaction () at xact.c:1543
#7  0x080a2af5 in CommitTransactionCommand () at xact.c:1938
#8  0x0819caef in finish_xact_command () at postgres.c:1843
#9  0x0819b795 in exec_simple_query (query_string=0x834ee8c "drop table
lijst61_table") at postgres.c:965
#10 0x0819dce0 in PostgresMain (argc=4, argv=0x8308b0c, username=0x8308adc
"megaconv") at postgres.c:2986
#11 0x08171f31 in BackendRun (port=0x83177f0) at postmaster.c:2817
#12 0x08171991 in BackendStartup (port=0x83177f0) at postmaster.c:2453
#13 0x0816ff6f in ServerLoop () at postmaster.c:1198
#14 0x0816f4a3 in PostmasterMain (argc=3, argv=0x8307788) at postmaster.c:917
#15 0x0813d22d in main (argc=3, argv=0x8307788) at main.c:268
#16 0x400f5d06 in __libc_start_main () from /lib/libc.so.6
(gdb) cont





--
Best,




Frank.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running