Thread: FATAL errors a plenty
DEBUG: XLogWrite: new log file created - consider increasing WAL_FILES DEBUG: XLogWrite: new log file created - consider increasing WAL_FILES ERROR: Cannot insert a duplicate key into unique index pk_inmail DEBUG: MoveOfflineLogs: remove 0000000300000049 DEBUG: MoveOfflineLogs: remove 0000000300000048 ERROR: Cannot insert a duplicate key into unique index pk_inmail NOTICE: current transaction is aborted, queries ignored until end of transaction block ERROR: Cannot insert a duplicate key into unique index pk_inmail NOTICE: current transaction is aborted, queries ignored until end of transaction block DEBUG: MoveOfflineLogs: remove 000000030000004A DEBUG: MoveOfflineLogs: remove 000000030000004B ERROR: Cannot insert a duplicate key into unique index pk_inmail NOTICE: current transaction is aborted, queries ignored until end of transaction block I have no clue at all - novice doesn't even begin to describe my lack of knowledge. What I would like to know is what this is, why this is, and if anyone knows how to fix it. More goodies that may or may not help: > Welcome to psql, 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 > > funnymail=# select count(*) from members_; > FATAL 2: XLogFlush: request is not satisfied > FATAL 2: XLogFlush: request is not satisfied > pqReadData() -- backend closed the channel unexpectedly. > This probably means the backend terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Server > process (pid > 3409) exited with status 512 at MNOTICE: Message from PostgreSQL backend: > The Postmaster has informed me that some other backend died > abnormally and possibly corrupted shared memory. > I have rolled back the current transaction and am going to > terminate your database system connection and exit. > Please reconnect to the database system and repeat your query. > Failed. > Server processes were terminated at Mon Sep 15 10:04:10 2003 > Reinitializing shared memory and semaphores > !# DEBUG: database system was interrupted at 2003-09-15 10:00:08 EDT > DEBUG: CheckPoint record at (3, 1152946868) > DEBUG: Redo record at (3, 1152946868); Undo record at (0, 0); > Shutdown TRUE > DEBUG: NextTransactionId: 8637182; NextOid: 6369864 > DEBUG: database system was not properly shut down; automatic recovery in > progress... > DEBUG: ReadRecord: record with zero len at (3, 1152946932) > DEBUG: redo is not required > DEBUG: database system is in production state > ----------------------------------------------------- > funnymail=# select * from members_ ; > FATAL 2: XLogFlush: request is not satisfied > Server process (pid 3416) exited with status 512 at Mon Sep 15 > 10:07:15 2003 > Terminating any active server processes... > Server processes were terminated at Mon Sep 15 10:07:15 2003 > Reinitializing shared memory and semaphores > DEBUG: database system was interrupted at 2003-09-15 10:04:12 EDT > DEBUG: CheckPoint record at (3, 1152946932) > DEBUG: Redo record at (3, 1152946932); Undo record at (0, 0); > Shutdown TRUE > DEBUG: NextTransactionId: 8637182; NextOid: 6369864 > DEBUG: database system was not properly shut down; automatic recovery in > progress... > DEBUG: ReadRecord: record with zero len at (3, 1152946996) > DEBUG: redo is not required > DEBUG: database system is in production state > FATAL 2: XLogFlush: request is not satisfied > pqReadData() -- backend closed the channel unexpectedly. > This probably means the backend terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Succeeded. > ------------------------------------------------------------------- This is a two server set up, postgres is on one server, the software using postgres is on another. Both are unix machines with the same version of redhat on them. I'm getting rather desperate on this.. anything anyone can do will be met with GREAT appreciation, cash grants are negotiable. Mickey
"Mickey" <mickey@mcnjeni.com> writes: >> FATAL 2: XLogFlush: request is not satisfied It looks like you are suffering from a corrupted LSN value in the header of one or more data pages. You didn't favor us with any mention of your Postgres version, but from spelling of the error messages I venture that it's 7.1.something. 7.1 is known not to be very robust in this situation :-(. What you need to do is extract whatever data you need (or can get anyway) and then update to something more modern and reload the database. You should really be on 7.2.4 or better 7.3.4. Can you pg_dump successfully? If not, do you really need the data in the members_ table, or can that be reconstructed from somewhere else? If the latter, drop that table and try to dump again. If the former, you'll have to resign yourself to some data loss, but you could theoretically zero the damaged page(s) and still read the rest of the table. The trouble is finding which pages are damaged --- 7.1 won't give you a lot of help on that either :-(. Best bet I know of is to use pg_filedump (http://sources.redhat.com/rhdb/) and look to see which pages in the members_ file have headers that don't look like the other pages. Somewhere along here you should also give some thought to what it was that got you into this situation. It'd not be a wise idea to assume that it was a Postgres bug. (I'm not saying that it wasn't, mind you, but several years later we still have not found any bugs that might clobber page headers.) Before trying to put your database back in production, I'd suggest looking for hardware problems (memtest86 and badblocks are commonly used to test RAM and disk respectively). Also see whether you shouldn't be using a more recent Linux kernel. regards, tom lane
The duplicate key errors are caused by attempting to insert a duplicate
value into a column, in this case pk_inmail, that has a unique index on
it -- meaning that only unique values are allowed in this column. If
you want to allow duplicate values, you can drop the index, then
re-index the column without the unique attribute, or drop the index
altogether. Either that, or clean up the data to be inserted, so that
the values for this column are indeed unique.
Help on the other errors will have to come from others on this list, I'm
afraid, but maybe this will get you started.
Louise
-----Original Message-----
From: pgsql-novice-owner@postgresql.org
[mailto:pgsql-novice-owner@postgresql.org] On Behalf Of Mickey
Sent: Monday, September 15, 2003 9:31 PM
To: pgsql-novice@postgresql.org
Subject: [NOVICE] FATAL errors a plenty
DEBUG: XLogWrite: new log file created - consider increasing WAL_FILES
DEBUG: XLogWrite: new log file created - consider increasing WAL_FILES
ERROR: Cannot insert a duplicate key into unique index pk_inmail
DEBUG: MoveOfflineLogs: remove 0000000300000049
DEBUG: MoveOfflineLogs: remove 0000000300000048
ERROR: Cannot insert a duplicate key into unique index pk_inmail
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
ERROR: Cannot insert a duplicate key into unique index pk_inmail
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: MoveOfflineLogs: remove 000000030000004A
DEBUG: MoveOfflineLogs: remove 000000030000004B
ERROR: Cannot insert a duplicate key into unique index pk_inmail
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
I have no clue at all - novice doesn't even begin to describe my lack of
knowledge.
What I would like to know is what this is, why this is, and if anyone
knows
how to fix it.
More goodies that may or may not help:
> Welcome to psql, 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
>
> funnymail=# select count(*) from members_;
> FATAL 2: XLogFlush: request is not satisfied
> FATAL 2: XLogFlush: request is not satisfied
> pqReadData() -- backend closed the channel unexpectedly.
> This probably means the backend terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Server
> process (pid
> 3409) exited with status 512 at MNOTICE: Message from PostgreSQL
backend:
> The Postmaster has informed me that some other backend died
> abnormally and possibly corrupted shared memory.
> I have rolled back the current transaction and am going
to
> terminate your database system connection and exit.
> Please reconnect to the database system and repeat your query.
> Failed.
> Server processes were terminated at Mon Sep 15 10:04:10 2003
> Reinitializing shared memory and semaphores
> !# DEBUG: database system was interrupted at 2003-09-15 10:00:08 EDT
> DEBUG: CheckPoint record at (3, 1152946868)
> DEBUG: Redo record at (3, 1152946868); Undo record at (0, 0);
> Shutdown TRUE
> DEBUG: NextTransactionId: 8637182; NextOid: 6369864
> DEBUG: database system was not properly shut down; automatic recovery
in
> progress...
> DEBUG: ReadRecord: record with zero len at (3, 1152946932)
> DEBUG: redo is not required
> DEBUG: database system is in production state
> -----------------------------------------------------
> funnymail=# select * from members_ ;
> FATAL 2: XLogFlush: request is not satisfied
> Server process (pid 3416) exited with status 512 at Mon Sep 15
> 10:07:15 2003
> Terminating any active server processes...
> Server processes were terminated at Mon Sep 15 10:07:15 2003
> Reinitializing shared memory and semaphores
> DEBUG: database system was interrupted at 2003-09-15 10:04:12 EDT
> DEBUG: CheckPoint record at (3, 1152946932)
> DEBUG: Redo record at (3, 1152946932); Undo record at (0, 0);
> Shutdown TRUE
> DEBUG: NextTransactionId: 8637182; NextOid: 6369864
> DEBUG: database system was not properly shut down; automatic recovery
in
> progress...
> DEBUG: ReadRecord: record with zero len at (3, 1152946996)
> DEBUG: redo is not required
> DEBUG: database system is in production state
> FATAL 2: XLogFlush: request is not satisfied
> pqReadData() -- backend closed the channel unexpectedly.
> This probably means the backend terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Succeeded.
> -------------------------------------------------------------------
This is a two server set up, postgres is on one server, the software
using
postgres is on another. Both are unix machines with the same version of
redhat on them.
I'm getting rather desperate on this.. anything anyone can do will be
met
with GREAT appreciation, cash grants are negotiable.
Mickey
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html