Thread: Server process exited with unexpected status 128.
Hello pgsql-hackers, When I try to execute the next SQL statement, sever was crashed: DELETE FROM ma_data WHERE id in (-1,212803,..... );... - is 500k text like id separated by ",". Its about 100000 values. Run from pgplsql function, like EXECUTE st;. postgresql-2005-09-25_000000.log: 2005-09-26 15:45:52 LOG: server process (PID 2040) exited with unexpected status 128 2005-09-26 15:45:52 LOG: terminating any other active server processes 2005-09-26 15:45:52 WARNING: terminating connection because of crash of another server process 2005-09-26 15:45:52 DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit,because another server process exited abnormally and possibly corrupted shared memory. 2005-09-26 15:45:52 HINT: In a moment you should be able to reconnect to the database and repeat your command. 2005-09-26 15:45:52 WARNING: terminating connection because of crash of another server process 2005-09-26 15:45:52 DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit,because another server process exited abnormally and possibly corrupted shared memory. 2005-09-26 15:45:52 HINT: In a moment you should be able to reconnect to the database and repeat your command. 2005-09-26 15:45:52 WARNING: terminating connection because of crash of another server process 2005-09-26 15:45:52 DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit,because another server process exited abnormally and possibly corrupted shared memory. 2005-09-26 15:45:52 HINT: In a moment you should be able to reconnect to the database and repeat your command. 2005-09-26 15:45:52 LOG: all server processes terminated; reinitializing 2005-09-26 15:45:52 LOG: database system was interrupted at 2005-09-26 15:45:48 FLE Daylight Time 2005-09-26 15:45:52 LOG: checkpoint record is at 1/1720CF88 2005-09-26 15:45:52 LOG: redo record is at 1/17008C80; undo record is at 0/0; shutdown FALSE 2005-09-26 15:45:52 LOG: next transaction ID: 40476; next OID: 1836657 2005-09-26 15:45:52 LOG: next MultiXactId: 102; next MultiXactOffset: 202 2005-09-26 15:45:52 LOG: database system was not properly shut down; automatic recovery in progress 2005-09-26 15:45:52 LOG: redo starts at 1/17008C80 2005-09-26 15:45:53 LOG: unexpected pageaddr 1/11A7C000 in log file 1, segment 24, offset 10993664 2005-09-26 15:45:53 LOG: redo done at 1/18A7AA08 2005-09-26 15:46:02 LOG: database system is ready #--------------------------------------------------------------------------- # RESOURCE USAGE (except WAL) #--------------------------------------------------------------------------- # - Memory - shared_buffers = 8000 # min 16 or max_connections*2, 8KB each temp_buffers = 10000 # min 100, 8KB each #max_prepared_transactions = 5 # can be 0 or more # note: increasing max_prepared_transactions costs ~600 bytes of shared memory # per transaction slot, plus lock space (see max_locks_per_transaction). work_mem = 200000 # min 64, size in KB maintenance_work_mem = 65536 # min 1024, size in KB max_stack_depth = 65536 # min 100, size in KB PG 8.1beta2 WIN32. -- С наилучшими пожеланиями, Репко Андрей Владимирович mailto:repko@sart.must-ipra.com
Андрей Репко <repko@sart.must-ipra.com> writes:
> When I try to execute the next SQL statement, sever was crashed:
> DELETE FROM ma_data WHERE id in (-1,212803,..... );
> ... - is 500k text like id separated by ",". Its about 100000 values.
I wouldn't be too surprised that that ran the server out of memory. The
recovery ought to be a little more graceful though :-( ... and it is, on
my machine:
ERROR: stack depth limit exceeded
HINT: Increase the configuration parameter "max_stack_depth".
CONTEXT: SQL statement "DELETE FROM ma_data WHERE id in (1,2,3,4,5,6,7,8,
... much omitted ...
99990,99991,99992,99993,99994,99995,99996,99997,99998,99999,100000,0);"PL/pgSQL function "blowup" line 7 at execute
statement
I'm guessing something wrong with the stack depth check on Windows.
It's passing the regression test though, so maybe the issue is specific
to your machine? What variant of Windows have you got exactly?
regards, tom lane
[ looking again... ]
Андрей Репко <repko@sart.must-ipra.com> writes:
> max_stack_depth = 65536 # min 100, size in KB
Hmm, maybe this is the problem. Are we sure Windows will allow a 64M stack?
regards, tom lane
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane > Sent: 26 September 2005 15:47 > To: Андрей Репко > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Server process exited with unexpected > status 128. > > [ looking again... ] > > Андрей Репко > <repko@sart.must-ipra.com> writes: > > max_stack_depth = 65536 # min 100, size in KB > > Hmm, maybe this is the problem. Are we sure Windows will > allow a 64M stack? Looks like we used 4MB in the backend by default: http://archives.postgresql.org/pgsql-committers/2005-01/msg00386.php Regards, Dave.
"Dave Page" <dpage@vale-housing.co.uk> writes: >> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane >>> max_stack_depth = 65536 # min 100, size in KB >> >> Hmm, maybe this is the problem. Are we sure Windows will >> allow a 64M stack? > Looks like we used 4MB in the backend by default: > http://archives.postgresql.org/pgsql-committers/2005-01/msg00386.php D'oh. Well, at the very least we have a documentation issue here. Is it sensible to try to prevent people from raising the GUC variable higher than the platform will allow? It seems we can know the limit on Windows, but on most other platforms I don't think there's any good way to find it out. (Which is why max_stack_depth is a SUSET variable --- you're assumed to know what you are doing if you change it.) regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 26 September 2005 16:01 > To: Dave Page > Cc: Андрей Репко; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Server process exited with unexpected > status 128. > > "Dave Page" <dpage@vale-housing.co.uk> writes: > >> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane > >>> max_stack_depth = 65536 # min 100, size in KB > >> > >> Hmm, maybe this is the problem. Are we sure Windows will > >> allow a 64M stack? > > > Looks like we used 4MB in the backend by default: > > http://archives.postgresql.org/pgsql-committers/2005-01/msg00386.php > > D'oh. Well, at the very least we have a documentation issue here. > > Is it sensible to try to prevent people from raising the GUC variable > higher than the platform will allow? It seems we can know > the limit on > Windows, but on most other platforms I don't think there's > any good way > to find it out. (Which is why max_stack_depth is a SUSET variable --- > you're assumed to know what you are doing if you change it.) I think It's sensible if it's a limit we can find relatively easily. In this case though it sounds like this is not the case. Perhaps we could issue a warning at startup if the value seems like it might be over the top? I assume the current limitis purely down to the data type. Regards, Dave
Tom Lane wrote: > Is it sensible to try to prevent people from raising the GUC variable > higher than the platform will allow? It seems we can know the limit on > Windows, but on most other platforms I don't think there's any good way > to find it out. (Which is why max_stack_depth is a SUSET variable --- > you're assumed to know what you are doing if you change it.) > I have PL/Java users that set a ridiculously high value in max_stack_depth just to circumvent the check altogether since it breaks when the executes code using another thread then main (see previous discussion "stack depth limit exceeded problem" started 9/23 for more info). If you plan to limit the GUC setting, please, *please*, also provide a way for PL/Java to switch stack_base. I will write the patch immediately if you approve. Regards, Thomas Hallgren