PostgreSQL 8.4 Tablespace Inconsistency

From: Harold Falkmeyer <hfalkmeyer(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: PostgreSQL 8.4 Tablespace Inconsistency
Date: 2019-08-09 04:33:57
Message-ID: CACcYrit01CxJ=z89Hv5ZCA39TVyi4HKxcFCpKBJs_9f-BmKoRg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello,

We operate a PostgreSQL 8.4.22 database on RHEL 6.10. Over the years,
we've attempted to intelligently distribute tables and indexes across
multiple tablespaces. After introducing a new tablespace, we attempted to
inventory which tables and indexes were on which tablespaces only to find
that pg_class indicated something inconsistent with our change records, as
well as with what we found on our filesystems.

As an example of the seeming inconsistency, pg_class indicated that certain
tables and indexes were on reltablespace 0, which, as we understood, refers
to pg_default, which, coincidentally is listed with pg_tablespace with oid
1663. That same pg_class object is clearly present on the filesystem for a
non-default tablespace.

As another example, pg_class lists no tables or indexes with one of our
non-default tablespace; though, that filesystem has a tablespace-like path
with many open files (lsof) listed whenever the database is running.

Our tablespaces were setup with CREATE TABLESPACE, ALTER TABLE ... SET
TABLESPACE, and ALTER INDEX ... SET TABLESPACE.

Thank you in advance for any insights and/or assistance you can provide,

Harold Falkmeyer

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ramesh Maddi 2019-08-09 06:28:57 Understanding PostgreSQL installer debug log
Previous Message Adrian Klaver 2019-08-08 21:25:59 Re: Why must AUTOCOMMIT be ON to do txn control in plpgsql procedure?