Re: Postgresql crash- any ideas?

Поиск
Список
Период
Сортировка
Искать

Re: Postgresql crash- any ideas?

От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Michael Guerin  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

Re: Postgresql crash- any ideas?

От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Michael Guerin  writes:
> Tom Lane wrote:
>> Michael Guerin  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

Re: Postgresql crash- any ideas?

От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Michael Guerin  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

Postgresql crash- any ideas?

От:
Michael Guerin <guerin@rentec.com>
Дата:
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

Re: Postgresql crash- any ideas?

От:
Michael Guerin <guerin@rentec.com>
Дата:
Tom Lane wrote:

>Michael Guerin  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
>  
>
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)
FAQ