Postgresql crash- any ideas?
Postgresql just reset itself, this is what I found in the log.
FATAL: block 26 of 1663/17228/3425958479 is still referenced (local 2)
LOG: server process (PID 1887) exited with exit code 1
LOG: terminating any other active server processes
There wasn't much activity in the database at the time. A vacuum on the entire database finished 5 minutes before this error and a vacuum of pg_attribute was in-progresss. re-vacuuming pg_attribute was ok.
pg version: 8 beta3
I only found this reference so far:
http://archives.postgresql.org/pgsql-bugs/2004-09/msg00029.php
-michael
Michael Guerin <guerin@rentec.com> writes:
Postgresql just reset itself, this is what I found in the log.
FATAL: block 26 of 1663/17228/3425958479 is still referenced (local 2)
LOG: server process (PID 1887) exited with exit code 1
LOG: terminating any other active server processes
pg version: 8 beta3
You sure that's beta3? Because we reduced that error condition from
FATAL to ERROR between beta2 and beta3. (And fixed the bug I think
you hit, too.)
regards, tom lane
Tom Lane wrote:
Michael Guerin <guerin@rentec.com> writes:
Postgresql just reset itself, this is what I found in the log.
FATAL: block 26 of 1663/17228/3425958479 is still referenced (local 2)
LOG: server process (PID 1887) exited with exit code 1
LOG: terminating any other active server processespg version: 8 beta3
You sure that's beta3? Because we reduced that error condition from
FATAL to ERROR between beta2 and beta3. (And fixed the bug I think
you hit, too.)regards, tom lane
fiasco=> select version();
version
------------------------------------------------------------------------------------------
PostgreSQL 8.0.0beta3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
3.3.1 (SuSE Linux)
(1 row)
Michael Guerin <guerin@rentec.com> writes:
Tom Lane wrote:
Michael Guerin <guerin@rentec.com> writes:
Postgresql just reset itself, this is what I found in the log.
FATAL: block 26 of 1663/17228/3425958479 is still referenced (local 2)You sure that's beta3? Because we reduced that error condition from
FATAL to ERROR between beta2 and beta3.
PostgreSQL 8.0.0beta3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
3.3.1 (SuSE Linux)
Well, I'd sure be interested to see a test case to reproduce it, then.
regards, tom lane
Michael Guerin <guerin@rentec.com> writes:
FATAL: block 26 of 1663/17228/3425958479 is still referenced (local 2)
LOG: server process (PID 1887) exited with exit code 1
After some contemplation of the source code I was able to isolate a
possibly-related failure case:
regression=# create temp table foo (f1 int) on commit delete rows;
CREATE TABLE
regression=# begin;
BEGIN
regression=# insert into foo values(1);
INSERT 1926679 1
regression=# insert into foo values(2);
INSERT 1926680 1
regression=# declare c cursor for select * from foo;
DECLARE CURSOR
regression=# fetch 1 from c;
f1
----
1
(1 row)
regression=# commit;
ERROR: block 0 of 1663/1788591/1926677 is still referenced (local 2)
regression=#
but as you can see this isn't FATAL, so I dunno if its the same as what
you are seeing.
This particular bug occurs because of a wrong order of operations during
COMMIT: we ought to close cursors *before* executing ON COMMIT actions.
regards, tom lane