On Mon, Oct 19, 2015 at 08:24:10AM -0700, Tom Lane wrote:
> Josip Rodin <joy+pgsql@xxxxxxxxxxxxxx> writes:
> > On Mon, Oct 19, 2015 at 11:42:38AM +0200, Andres Freund wrote:
> >>>> That's the wrong query. The files on disk are relefilenodes not
> >>>> oids. Try WHERE pg_relation_filenode(oid) IN ...
>
> > Oh, sorry, but yet again, there's just nothing there:
>
> > % sudo -H -u postgres psql mydb -c "SELECT oid, relname, relkind FROM pg_catalog.pg_class WHERE pg_relation_filenode(oid) IN (7877054, 7877056);"
> > oid | relname | relkind
> > -----+---------+---------
> > (0 rows)
>
> Seeing that those files are all of similar date, I wonder if they are
> tables that got orphaned in a crash, ie, the pg_class rows were removed
> but the backend crashed before physically unlinking the files.
>
> Anyway, if you've satisfied yourself that there are no pg_class entries
> for these files, you could just manually remove the files.
>
> I concur with Adrian's nearby suggestion of checking for rows with
> reltablespace matching the tablespace's OID before you do anything
> drastic, though.
OK, so given that that's all missing, too, I'm in the clear, then?
How likely would it be for the server to, at some point in the future, to
somehow deduce a new reference to that tablespace and do a FATAL when it
finds nothing there?
BTW how safe is the standby/failover idea in general? Changing pg_tblspc
across promotions, so to speak.
--
2. That which causes joy or happiness.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
