FATAL 1: Relation 'pg_shadow' does not exist
I am getting this error when I attempt to connect to a production
database. All other databases have valid pg_shadow and appear to be fine.
The database version is
PostgreSQL 7.1 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
Logging was going to the terminal (completely useless, I know) but there
was an interesting error from a VACUUM of another database on the system:
NOTICE: Rel qafinal_fti_i: TID 2023/112: OID IS INVALID. TUPGONE 0.
The affected database was not being vacuumed, not had it been since I'd
seen it 'stable'.
Does anyone have any ideas about this? Anything to prevent my needing to
go to tape and spend a long night in a cold cold server room?
Thanks
Gavin
Gavin Sherry wrote:
I am getting this error when I attempt to connect to a production
database. All other databases have valid pg_shadow and appear to be fine.The database version is
PostgreSQL 7.1 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
Logging was going to the terminal (completely useless, I know) but there
was an interesting error from a VACUUM of another database on the system:NOTICE: Rel qafinal_fti_i: TID 2023/112: OID IS INVALID. TUPGONE 0.
The affected database was not being vacuumed, not had it been since I'd
seen it 'stable'.Does anyone have any ideas about this? Anything to prevent my needing to
go to tape and spend a long night in a cold cold server room?
Can you connect to the db using standalone postgres ?
i.e.
postgres -P -O your_database_name
regards,
Hiroshi Inoue
Show quoted text
Thanks
Gavin
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
On Tue, 15 Jan 2002, Hiroshi Inoue wrote:
Does anyone have any ideas about this? Anything to prevent my needing to
go to tape and spend a long night in a cold cold server room?Can you connect to the db using standalone postgres ?
i.e.postgres -P -O your_database_name
When I first brought it down, I attempted this, but forgot -O. I've just
done this, however, it connected fine. Moreover, a select * from
pg_shadow; returned results! I vacuumed and brought the database back
online -- everything fine.
Extremely strange =\.
Gavin
Gavin Sherry <swm@linuxworld.com.au> writes:
When I first brought it down, I attempted this, but forgot -O. I've just
done this, however, it connected fine. Moreover, a select * from
pg_shadow; returned results! I vacuumed and brought the database back
online -- everything fine.
Extremely strange =\.
Did I read you correctly to say that you're still on 7.1?
This episode should convince you to update to 7.1.3, pronto.
We don't make dot-releases for amusement value.
(No, I can't cite any particular bug that might've led to this.)
regards, tom lane
Tom Lane wrote:
Gavin Sherry <swm@linuxworld.com.au> writes:
When I first brought it down, I attempted this, but forgot -O. I've just
done this, however, it connected fine. Moreover, a select * from
pg_shadow; returned results! I vacuumed and brought the database back
online -- everything fine.Extremely strange =\.
Did I read you correctly to say that you're still on 7.1?
This episode should convince you to update to 7.1.3, pronto.
We don't make dot-releases for amusement value.(No, I can't cite any particular bug that might've led to this.)
IIRC there was this cross DB shared buffer usage bug
somewhere in 7.1, that used blocks from another DB found by
accident in the cache. So it all must have been a cache
problem and the postmaster restart fix^H^H^H made it
disappear and lurk again.
That bug can corrupt the system catalogs of all your
databases! Upgrade NOW!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Jan Wieck <janwieck@yahoo.com> writes:
IIRC there was this cross DB shared buffer usage bug
somewhere in 7.1, that used blocks from another DB found by
accident in the cache.
No, we found that one before 7.1 release, thank goodness.
regards, tom lane
Tom Lane wrote:
Jan Wieck <janwieck@yahoo.com> writes:
IIRC there was this cross DB shared buffer usage bug
somewhere in 7.1, that used blocks from another DB found by
accident in the cache.No, we found that one before 7.1 release, thank goodness.
You're right, it was just Tim who ran on BETA in production
for far too long (from out POV).
Well, got me, out of ideas too.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com