FlushRelationBuffers error - Mailing list pgsql-hackers

From Gaetano Mendola
Subject FlushRelationBuffers error
Date
Msg-id cjgmdn$rd3$1@floppy.pyrenet.fr
Whole thread Raw
Responses Re: FlushRelationBuffers error  (Jan Wieck <JanWieck@Yahoo.com>)
Re: FlushRelationBuffers error  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi all,
I'm running postgres 7.4.5 on a linux box, this morning I got this error on my logs:

WARNING:  FlushRelationBuffers("exp_provider", 1836): block 1460 is referenced (private 0, global 1)
ERROR:  FlushRelationBuffers returned -2
DEBUG:  AbortCurrentTransaction
PANIC:  cannot abort transaction 354676201, it was already committed

after the recovery:

ERROR:  could not access status of transaction 352975274
DEBUG:  AbortCurrentTransaction

this messages for 5 hours



I had my verbosity equal to terse ( I run the server with debug2 level ) so I didn't see the
exactly reason for this, after putting verbosity to "verbose" I got the entire message:

ERROR:  58P01: could not access status of transaction 352975274
DETAIL:  could not open file "/var/lib/pgsql/data/pg_clog/0150": No such file or directory
LOCATION:  SlruReportIOError, slru.c:609
DEBUG:  00000: AbortCurrentTransaction
LOCATION:  PostgresMain, postgres.c:2721

In the pg_clog directory I had only the  file   0152 !


I had to create a 8k file with zeroes and I discover the offset:

ERROR:  XX000: could not access status of transaction 352975274
DETAIL:  could not read from file "/var/lib/pgsql/data/pg_clog/0150" at offset 155648: Success
LOCATION:  SlruReportIOError, slru.c:630
DEBUG:  00000: AbortCurrentTransaction
LOCATION:  PostgresMain, postgres.c:2721

After creating that file till to cover that offset the problem seems be fixed.

Info for hackers: exp_provider is an index and during that message a reindex was in place.

Some questions:
What about the 0151  file?
Don't you think that even with verbosity terse the message about the file missing shall appear ?
Why emit the offset only if the file was found ?

I have to thank Neil Conway that was helping me on IRC about this error.

If you need further infos, please let me know.

Regards
Gaetano Mendola



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: profile-guided opt. w/ GCC
Next
From: Stephan Szabo
Date:
Subject: Re: [PERFORM] spurious function execution in prepared statements.