Thread: Crash after VACUUM FULL cancel

I realize this is very little info to go on but our server had some
trouble this morning..

Postgres 8.2.4
Linux unicron.marketingsolutionsinc.com 2.6.15-1.2054_FC5smp #1 SMP Tue
Mar 14 16:05:46 EST 2006 i686 i686 i386 GNU/Linux


PID: 15980 - 2008-04-09 07:49:20 CDT - USER: postgres - DB:  maverick -
CMD: VACUUM - ERROR:  canceling statement due to user request
PID: 15980 - 2008-04-09 07:49:20 CDT - USER: postgres - DB:  maverick -
CMD: VACUUM - STATEMENT:  VACUUM FULL ANALYZE bsg_pike.accounts
PID: 15980 - 2008-04-09 07:49:20 CDT - USER: postgres - DB:  maverick -
CMD: VACUUM - PANIC:  cannot abort transaction 116388108, it was already
committed
PID: 4363 - 2008-04-09 07:49:20 CDT - USER:  - DB:   - CMD:  - LOG:
server process (PID 15980) was terminated by signal 6
PID: 4363 - 2008-04-09 07:49:20 CDT - USER:  - DB:   - CMD:  - LOG:
terminating any other active server processes
PID: 28867 - 2008-04-09 07:49:20 CDT - USER: skatz - DB:  maverick -
CMD: idle - WARNING:  terminating connection because of crash of another
server process
PID: 28867 - 2008-04-09 07:49:20 CDT - USER: skatz - DB:  maverick -
CMD: idle - 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.
PID: 28867 - 2008-04-09 07:49:20 CDT - USER: skatz - DB:  maverick -
CMD: idle - HINT:  In a moment you should be able to reconnect to the
database and repeat your command.
PID: 27424 - 2008-04-09 07:49:20 CDT - USER: bsg_pike - DB:  maverick -
CMD: SELECT waiting - WARNING:  terminating connection because of crash
of another server process
PID: 27424 - 2008-04-09 07:49:20 CDT - USER: bsg_pike - DB:  maverick -
CMD: SELECT waiting - 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.


We have a cronjob that runs nightly to do the VACUUM FULL ANALYZE on a
few tables in each schema and occasionally we'll cancel one if they take
longer than usual to run and block our morning loads.. This is the first
time Postgres has had any trouble with it.   Is cancelling a full vacuum
a bad idea?

I know I'm not going to find any solution to why it happened, I'm just
looking for anyone's take on it..

Thanks,
Joe

______________

The information contained in this message is proprietary and/or confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition,
please be aware that any message addressed to our domain is subject to archiving and review by
persons other than the intended recipient. Thank you.
_____________

Hardwick, Joe wrote:

> We have a cronjob that runs nightly to do the VACUUM FULL ANALYZE on a
> few tables in each schema and occasionally we'll cancel one if they take
> longer than usual to run and block our morning loads.. This is the first
> time Postgres has had any trouble with it.   Is cancelling a full vacuum
> a bad idea?

Yes -- this is a known problem but since VACUUM FULL is deprecated, the
most likely outcome is that it won't get fixed.  Just don't cancel it.

You don't need VACUUM FULL anyway in most cases -- plain VACUUM ANALYZE
should be more than enough.  For the rare cases that it's not, you can
use CLUSTER to compress the dead space.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support