Re: server crash in very big transaction [postgresql 8.0beta1] - Mailing list pgsql-bugs

From Tom Lane
Subject Re: server crash in very big transaction [postgresql 8.0beta1]
Date
Msg-id 12617.1093385440@sss.pgh.pa.us
Whole thread Raw
In response to Re: server crash in very big transaction [postgresql 8.0beta1]  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: server crash in very big transaction [postgresql 8.0beta1]
List pgsql-bugs
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> On Sun, Aug 22, 2004 at 09:39:07AM +0800, ?????? wrote:
>> PANIC:  invalid xlog record length 236052

> Huh, so what kind of operations did you execute within the transaction?

I found one possible explanation, though I don't know if it's the
submitter's problem or not.  Create a SQL file that generates a whole
lot of subtransactions, like more than 16000.  I used

begin;
create table foo(d1 int);
drop table foo;
savepoint x;
release x;
-- repeat above 2 lines 20000 times
commit;

First try gave me

WARNING:  out of shared memory
ERROR:  out of shared memory
HINT:  You may need to increase max_locks_per_transaction.
WARNING:  StartAbortedSubTransaction while in START state
ERROR:  current transaction is aborted, commands ignored until end of transaction block
ERROR:  current transaction is aborted, commands ignored until end of transaction block
... etc ...

which is fine except for the StartAbortedSubTransaction warning; that
may indicate a problem.  (What do you think about it, Alvaro?)

I bumped up max_locks_per_transaction to 1000 and tried again, and got

psql:zzbig.sql:40004: PANIC:  invalid xlog record length 80024
server closed the connection unexpectedly

What is happening of course is that more than 16K subtransaction IDs
won't fit in a commit record (since XLOG records have a 16-bit length
field).  We're gonna have to rethink the representation of subxact
commit in XLOG.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "PostgreSQL Bugs List"
Date:
Subject: BUG #1230: mirror problem
Next
From: Josh Berkus
Date:
Subject: Backward compatibility issue with 8.0b1