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@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +