Re: create tablespace fails silently, or succeeds improperly

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: create tablespace fails silently, or succeeds improperly
Date: 2010-10-18 18:56:03
Message-ID: 201010181856.o9IIu3t06799@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dave Cramer wrote:
> >> >> > postgres=# select version();
> >> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? version
> >> >> > -------------------------------------------------------------------------------------------------------------------
> >> >> > ?PostgreSQL 9.0.1 on x86_64-unknown-linux-gnu, compiled by GCC gcc
> >> >> > (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11), 64-bit
> >> >> > (1 row)
> >> >> >
> >> >> > postgres=# create TABLESPACE jnj_indexes location '/opt/pg/data/jnj_indexes';
> >> >> > CREATE TABLESPACE
> >> >>
> >> >> IIRC the reason this works is that the tablespace code now creates a
> >> >> version-specific subdirectory inside the specified directory. ?This was
> >> >> done to help binary upgrades.
> >> >
> >> > Right, the directory is catalog-version named, which was done to allow
> >> > for pg_upgrade to work for alpha/beta upgrades (pretty cool). ?The case
> >> > above happened because 8.4 still has data in that tablespace.
> >> > pg_upgrade does supply a script to delete old data files, but it was not
> >> > used in the case above.
> >> >
> >>
> >> right that's because I did not use pg_upgrade. I was manually running
> >> create tablespace.
> >
> > OK, so you were sharing the tablespace with old and new clusters. ?You
> > are right that in the past that would not have been possible because
> > PG_VERSION would have conflicted, but it is now possible with all new
> > releases because of the catalog-version-named subdirectory. ?That seems
> > like I a feature, I guess.
> >
>
> Sounds unintended. As it turns out I was expecting it to fail and was
> surprised when it succeeded.

Well, it was intended, or rather required by pg_upgrade.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-10-18 18:57:11 Re: create tablespace fails silently, or succeeds improperly
Previous Message Tom Lane 2010-10-18 18:49:28 Re: Floating-point timestamps versus Range Types