I realize this is very little info to go on but our server had some
trouble this morning..=20
Postgres 8.2.4=20
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
confidentia=
l. If you are not the=20
intended recipient, please: (i) delete the message and all copies; (ii) do
=
not disclose,=20
distribute or use the message in any manner; and (iii) notify the sender
im=
mediately. In addition,=20
please be aware that any message addressed to our domain is subject to
arch=
iving and review by=20
persons other than the intended recipient. Thank you.
_____________
--=20
Sent via pgsql-general mailing list (pgsql-general@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
|
