Thread: xlog flush request 0/215D32E4 is not satisfied
Can anyone help me with this problem; we are just about to go live (February 1), and all of a sudden our main database has an 'issue'. I'd like to save the database if possible, if not, then I'll rebuild it from scratch which I absolutely don't want to do since it will take about a month of continuous work.
That said, I did a search on 'xlog flush request' and the only hits I got were on version 7.1, and I'm using 7.4. In the other post, someone had run pg_resetxlog, but I remember seeing somewhere serious warnings against using that utility, especially if one runs it as root. If I'm suggested to run it, should I run it as user postgres or myself?
I tried to do a 'pg_dump -d bwks > crash.dump' and got a failure.
Below please find the two different errors I get, the first is the 'xlog flush' error and below that is the 'pg_dump error'.
Thank you in advance for your help.
Welcome to psql 7.4.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
bwks=# \d product
ERROR: xlog flush request 0/215D32E4 is not satisfied --- flushed only to 0/15138F7C
CONTEXT: writing block 4 of relation 17143/1682159
bwks=# select * from product;
code | short_desc | unit_value | unit_price | eff_date | term_date | product_id | code_type_id | last_edit_user | last_edit_ts | ledger_column | patient_resp | voucher_item | description
------+------------+------------+------------+----------+-----------+------------+--------------+----------------+--------------+---------------+--------------+--------------+-------------
(0 rows)
bwks=# \q
_____________________________________________
$ pg_dump -d bwks > 2005.dumpall.crash
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: xlog flush request 0/215D738C is not satisfied --- flushed only to 0/15138F7C
CONTEXT: writing block 5 of relation 17143/1682159
pg_dump: The command was: SELECT (SELECT usename FROM pg_user WHERE usesysid = datdba) as dba, pg_encoding_to_char(encoding) as encoding, datpath FROM pg_database WHERE datname = 'bwks'
Tim Vadnais <tvadnais@bwks.com> writes:
> bwks=# \d product
> ERROR: xlog flush request 0/215D32E4 is not satisfied --- flushed only to
> 0/15138F7C
> CONTEXT: writing block 4 of relation 17143/1682159
This looks to me like a corrupted-data problem: specifically, the LSN
field of that particular page is pointing far past the actual end of
WAL. Unless you've been fooling with pg_resetxlog in the past on this
installation, the logical suspicion is some dropped bits either in RAM
or on disk. You might want to dig out pg_filedump or some such tool
(even plain old "od", in a pinch) and have a look at that page to see if
you can make any sense of what happened to it.
> pg_dump: Error message from server: ERROR: xlog flush request 0/215D738C is
> not satisfied --- flushed only to 0/15138F7C
> CONTEXT: writing block 5 of relation 17143/1682159
It seems more than a tad odd that two different pages would have bogus
LSNs so close together, though. Are you sure no one has been taking
liberties with the DB, like trying to copy physical files from a
different installation?
regards, tom lane