Обсуждение: New kind of crash?
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
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 On 09/03/13 13:27, Josh Berkus wrote: > 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 wrote: > Folks, >=20 > This is one I've never seen before: >=20 > =3D> 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. --=20 =C1lvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 03/08/2013 07:27 PM, Alvaro Herrera wrote: > Josh Berkus wrote: >> 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 > > 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
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
Josh Berkus wrote: > On 03/08/2013 07:27 PM, Alvaro Herrera wrote: > > Josh Berkus wrote: > >> Folks, > >> > >> This is one I've never seen before: > >> > >> =3D> select generate_master_tables(); > >> WARNING: AbortTransaction while in COMMIT state > >> PANIC: cannot abort transaction 9387287, it was already committed > >=20 > > 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 tha= t > > was already full because of lock objects. >=20 > 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. --=20 =C1lvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Alvaro, BTW, we haven't been able to reproduce this crash deliberately, yet. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com