By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,934 Members | 1,685 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,934 IT Pros & Developers. It's quick & easy.

FW: database failure..

P: n/a


Nobody got any ideas on the below problem? :-(

[root /tmp]# psql -V
psql (PostgreSQL) 7.0.2
contains readline, history, multibyte support
Portions Copyright (c) 1996-2000, PostgreSQL, Inc
Portions Copyright (c) 1996 Regents of the University of California Read
the file COPYRIGHT or use the command \copyright to see the usage and
distribution terms.

Nothing at all in the logs...How do I change the debugging/log level to
show more?

NB. a few of the DBs on the server dont have any problems at all...

Jason

-----Original Message-----
From: Marc G. Fournier [mailto:sc*****@postgresql.org]
Sent: Sunday, December 14, 2003 8:00 PM
To: Ausrack Webmaster
Cc: pg***********@postgresql.org
Subject: Re: [GENERAL] database failure..
On Sun, 14 Dec 2003, Ausrack Webmaster wrote:

Hi,

I have a database, which just happens to be the main database on a
RAQ4..(cobalt)
that even when recreated it still dies, even before readding any
tables..

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

cobalt=# \d
The connection to the server was lost. Attempting reset: Succeeded.

I can't dump either..

getTables(): SELECT failed. Explanation from backend: 'pqReadData()
-- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
'.

Any idea what might be causing this?


anything in the logs? hardware failure maybe? what version of
database?

----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ:
7615664

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Ausrack Webmaster wrote:

Nobody got any ideas on the below problem? :-(
From the behaviour I would guess there is something corrupt in one of
the system catalogs of that database. Make sure the coredump size of the
postmaster process is unlimited, recreate the problem and you should
find a file named "core" in the data directory of that database.
Hopefully the postgres executable was built with enough symbol
information so that you can get a stack backtrace from that core file
with a debugger.
Jan

[root /tmp]# psql -V
psql (PostgreSQL) 7.0.2
contains readline, history, multibyte support
Portions Copyright (c) 1996-2000, PostgreSQL, Inc
Portions Copyright (c) 1996 Regents of the University of California Read
the file COPYRIGHT or use the command \copyright to see the usage and
distribution terms.

Nothing at all in the logs...How do I change the debugging/log level to
show more?

NB. a few of the DBs on the server dont have any problems at all...

Jason

-----Original Message-----
From: Marc G. Fournier [mailto:sc*****@postgresql.org]
Sent: Sunday, December 14, 2003 8:00 PM
To: Ausrack Webmaster
Cc: pg***********@postgresql.org
Subject: Re: [GENERAL] database failure..
On Sun, 14 Dec 2003, Ausrack Webmaster wrote:

Hi,

I have a database, which just happens to be the main database on a
RAQ4..(cobalt)
that even when recreated it still dies, even before readding any
tables..

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

cobalt=# \d
The connection to the server was lost. Attempting reset: Succeeded.

I can't dump either..

getTables(): SELECT failed. Explanation from backend: 'pqReadData()
-- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
'.

Any idea what might be causing this?


anything in the logs? hardware failure maybe? what version of
database?

----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ:
7615664

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

--
#================================================= =====================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================= = Ja******@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #2

P: n/a
You're gonna have a hard time getting support for a version that old
(we've since seen 7.1, 7.2, 7.3, and 7.4 come out and 7.5 is in the cooker
right now.

If it's possible to backup your database, I'd highly recommend upgrading
postgresql on a test machine or something. It sounds like you might have
a bad block on your hard drive, or possible 7.0.2 has managed to corrupt
the data files all on its own.

Note that 7.0.3 was the last of that line, so even if you're gonna stick
with 7.0.x, you should be running that version.

Each version of Postgresql since 6.5.x has gotten faster and more stable
in my experience, and many bugs have been squashed since the time that 7.0
was put out.

If you can backup the drive postgresql is on file level wise and test it
for bad blocks, that would be good, if it's IDE it might do well being
reformatted.

Also, look at running memtest86 on the box to make sure you don't have
flakey memory. (www.memtest86.com, it's free)

On Tue, 16 Dec 2003, Ausrack Webmaster wrote:


Nobody got any ideas on the below problem? :-(

[root /tmp]# psql -V
psql (PostgreSQL) 7.0.2
contains readline, history, multibyte support
Portions Copyright (c) 1996-2000, PostgreSQL, Inc
Portions Copyright (c) 1996 Regents of the University of California Read
the file COPYRIGHT or use the command \copyright to see the usage and
distribution terms.

Nothing at all in the logs...How do I change the debugging/log level to
show more?

NB. a few of the DBs on the server dont have any problems at all...

Jason

-----Original Message-----
From: Marc G. Fournier [mailto:sc*****@postgresql.org]
Sent: Sunday, December 14, 2003 8:00 PM
To: Ausrack Webmaster
Cc: pg***********@postgresql.org
Subject: Re: [GENERAL] database failure..
On Sun, 14 Dec 2003, Ausrack Webmaster wrote:

Hi,

I have a database, which just happens to be the main database on a
RAQ4..(cobalt)
that even when recreated it still dies, even before readding any
tables..

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

cobalt=# \d
The connection to the server was lost. Attempting reset: Succeeded.

I can't dump either..

getTables(): SELECT failed. Explanation from backend: 'pqReadData()
-- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
'.

Any idea what might be causing this?


anything in the logs? hardware failure maybe? what version of
database?

----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ:
7615664

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.