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

pg_dumpall dies

P: n/a
I just been choosen as sys adm on a small network. We have a old Sun Ultra
1 running postgresql 7.1.3. I would like to migrate the database to a new
machine and a newer version of postgresql. But when I run the pg_dumpall
command I get the followering error, after a while:

WARNING: owner of type 'counter' appears to be invalid
dumpRules(): SELECT failed for rules associated with table "counter".
Explanation from backend: 'pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
'.
pg_dump failed on obeladmin, exiting

"counter" is a sequence and it's owner is postgres

Any help is appreciated

--
Mvh. / Kind regards
Henrik Farre

http://www.rockhopper.dk

Nov 22 '05 #1
Share this Question
Share on Google+
3 Replies

P: n/a
Henrik Farre <lo**@my.signature.txt> writes:
I just been choosen as sys adm on a small network. We have a old Sun Ultra
1 running postgresql 7.1.3. I would like to migrate the database to a new
machine and a newer version of postgresql. But when I run the pg_dumpall
command I get the followering error, after a while: WARNING: owner of type 'counter' appears to be invalid
dumpRules(): SELECT failed for rules associated with table "counter".
Explanation from backend: 'pqReadData() -- backend closed the channel unexpectedly.


It sounds like you have a badly corrupted database :-(. However, the
pg_dump message is of little help in delving further than that. What
shows up in the postmaster log? If the backend is dumping core, can
you get a stack trace?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 22 '05 #2

P: n/a
Den Fri, 20 Feb 2004 23:55:33 -0500. skrev Tom Lane:
It sounds like you have a badly corrupted database :-(. However, the
pg_dump message is of little help in delving further than that. What
shows up in the postmaster log? If the backend is dumping core, can
you get a stack trace?


The followering is from the log:

2004-02-21 12:52:49 DEBUG: query: SELECT definition, (select usename from pg_user where pg_class.relowner = usesysid) AS viewowner, pg_rewrite.oid, pg_rewrite.rulename FROM pg_rewrite, pg_class, pg_rules WHERE pg_class.relname = 'counter' AND pg_rewrite.ev_class = pg_class.oid AND pg_rules.tablename = pg_class.relname AND pg_rules.rulename = pg_rewrite.rulename ORDER BY pg_rewrite.oid
Server process (pid 24536) exited with status 138 at Sat Feb 21 12:52:49 2004
Terminating any active server processes...
2004-02-21 12:52:49 NOTICE: 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.

The notice is repeated 8 times.

I have set "ulimit -c coredumpsize", but I don't get a core dump.

--
Mvh. / Kind regards
Henrik Farre

http://www.rockhopper.dk

Nov 22 '05 #3

P: n/a
Henrik Farre <lo**@my.signature.txt> writes:
Server process (pid 24536) exited with status 138 at Sat Feb 21 12:52:49 2004
Terminating any active server processes... I have set "ulimit -c coredumpsize", but I don't get a core dump.


You certainly should get a core dump. Are you sure you set the ulimit
in the postmaster's starting environment? Did you look for the core
file in the right place? A backend will dump core in the directory
of its database, that is, $PGDATA/base/your-db-oid/core.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.