Re: pg_tables bug?

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Gaetano Mendola <mendola(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_tables bug?
Date: 2015-12-17 11:56:49
Message-ID: CAB7nPqR46h1ChtuKj1Gn83LTTM2n8O-d1Zaz2T4FeWYLSKgimA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 17, 2015 at 4:54 PM, Gaetano Mendola <mendola(at)gmail(dot)com> wrote:
> I'm playing around with tablespace (postgresq 9.4) and I found out what I
> believe is a bug in pg_tables.
> Basically if you create a database in a table space X and then you create a
> table on the database the table is created correctly on the tablespace X ( I
> did a check on the filesystem) however if you do a select on pg_tables the
> column tablespace for that table is empty and even worst if you dump the DB
> there is no reporting about the the database or table being on that
> tablespace.
> Even \d doesn't report that the table is in the tablespace X.

Are you sure you created the table in a tablespace? See for example:
=# create tablespace popo location '/to/tbspace/path';
CREATE TABLESPACE
=# create table aa (a int) tablespace popo;
CREATE TABLE
=# \d aa
Table "public.aa"
Column | Type | Modifiers
--------+---------+-----------
a | integer |
Tablespace: "popo"
=# select tablename, tablespace from pg_tables where tablename = 'aa';
tablename | tablespace
-----------+------------
aa | popo
(1 row)

Regards,
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message YUriy Zhuravlev 2015-12-17 12:23:47 Small fix in pg_rewind (redundant declaration)
Previous Message Michael Paquier 2015-12-17 11:45:42 Re: extend pgbench expressions with functions