Thread: 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 > > 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