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
=?Windows-1251?Q?=C0=ED=E4=F0=E5=E9_=D0=E5=EF=EA=EE?= <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... ]
=?Windows-1251?Q?=C0=ED=E4=F0=E5=E9_=D0=E5=EF=EA=EE?= <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... ]
=?Windows-1251?Q?=C0=ED=E4=F0=E5=E9_=D0=E5=EF=EA=EE?=
<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.
Import Notes
Resolved by subject fallback
"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.phpD'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 limit is purely down to the data type.
Regards, Dave
Import Notes
Resolved by subject fallback
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