Re: PostgreSQL 8.4 Tablespace Inconsistency

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Harold Falkmeyer <hfalkmeyer(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: PostgreSQL 8.4 Tablespace Inconsistency
Date: 2019-08-09 14:15:23
Message-ID: 4064.1565360123@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Harold Falkmeyer <hfalkmeyer(at)gmail(dot)com> writes:
> 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.

No, reltablespace = 0 means that the relation is in its database's default
tablespace; that's whatever pg_database.dattablespace says, not
necessarily pg_default. The reason for this is basically to allow a
database to be moved en-masse to another tablespace without having
to update its pg_class.

> 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.

Maybe those objects are in a different database of the cluster?

Another thought is to take a close look at the symlinks in
$PGDATA/pg_tblspc to verify that your tablespaces are pointing
where you think they are. Note that pg_tablespace.spclocation
is not authoritative on this; the symlinks are.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2019-08-09 14:31:56 Re: PostgreSQL lock file
Previous Message Daniel Vos 2019-08-09 14:10:26 Re: ...