New kind of crash?

[Josh Berkus]

Folks,

This is one I've never seen before:

=> select generate_master_tables();
WARNING: AbortTransaction while in COMMIT state
PANIC: cannot abort transaction 9387287, it was already committed
PANIC: cannot abort transaction 9387287, it was already committed
The connection to the server was lost. Attempting reset: Failed.
Time: 42259.753 ms
!>

Interestingly, Postges came back up on its own after about a minute and
seems to be OK. The stored procedure in question is one which creates
about 600 tables. This actually exceeds max_locks_per_transaction, but
what happened above is not the normal failure for that.

Note that the tables were, in fact, created, and as far as I can tell
there's no corruption of the database.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

[Mark Kirkwood]

Do you have any non default procedural languages installed? I provoked
exactly that error with a similar script which used a PL/R procedure
(see BUGS thread "PL/R Median Busts Commit"...the cause is signal
hi-jacking in that case).

Regards

Mark

Post by Josh Berkus
Folks,
=> select generate_master_tables();
WARNING: AbortTransaction while in COMMIT state
PANIC: cannot abort transaction 9387287, it was already committed
PANIC: cannot abort transaction 9387287, it was already committed
The connection to the server was lost. Attempting reset: Failed.
Time: 42259.753 ms
!>
Interestingly, Postges came back up on its own after about a minute and
seems to be OK. The stored procedure in question is one which creates
about 600 tables. This actually exceeds max_locks_per_transaction, but
what happened above is not the normal failure for that.
Note that the tables were, in fact, created, and as far as I can tell
there's no corruption of the database.

[Alvaro Herrera]

Post by Josh Berkus
Folks,
=> select generate_master_tables();
WARNING: AbortTransaction while in COMMIT state
PANIC: cannot abort transaction 9387287, it was already committed

Anything that causes an ERROR in the final stages of a transaction
commit will look like this. Maybe, for example, something tried to
acquire more shared memory for something (serializable xact?) but that
was already full because of lock objects.

[Josh Berkus]

Post by Alvaro Herrera

Post by Josh Berkus
Folks,
=> select generate_master_tables();
WARNING: AbortTransaction while in COMMIT state
PANIC: cannot abort transaction 9387287, it was already committed

Anything that causes an ERROR in the final stages of a transaction
commit will look like this. Maybe, for example, something tried to
acquire more shared memory for something (serializable xact?) but that
was already full because of lock objects.

Well, is it worth trying to reproduce and diagnose?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

[Alvaro Herrera]

Post by Josh Berkus

Post by Alvaro Herrera

Post by Josh Berkus
Folks,
=> select generate_master_tables();
WARNING: AbortTransaction while in COMMIT state
PANIC: cannot abort transaction 9387287, it was already committed

Anything that causes an ERROR in the final stages of a transaction
commit will look like this. Maybe, for example, something tried to
acquire more shared memory for something (serializable xact?) but that
was already full because of lock objects.

Well, is it worth trying to reproduce and diagnose?

IMO it's worth adding enough protections that in these situations you
get regular ERRORs rather than PANICs, assuming the scenario is not too
contrived and the required patches are not too complex.

[Josh Berkus]

Alvaro,

BTW, we haven't been able to reproduce this crash deliberately, yet.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

[Josh Berkus]

Mark,

I have PL/R and PL/v8 installed on that server (as well as a few other
extensions). However, neither of those is invoked in the procedure
which caused the crash; it's straight PL/pgSQL.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com