Horton

Thread

  1. Re: create tablespace fails silently, or succeeds improperly

    Bruce Momjian <bruce@momjian.us> — 2010-10-19T02:37:18Z

    bruce wrote:
> Tom Lane wrote:
> > Dave Cramer <pg@fastcrypt.com> writes:
> > > as seen below create tablespace does not throw an error or appear to
> > > do anything other than register the tablespace.
> > 
> > I suspect this behavior is partially intentional, because tablespace
> > creation now involves an extra level of subdirectory.  However, it's
> > not clear to me why CREATE TABLESPACE is still changing the permissions
> > on the parent directory.  Bruce, exactly what is the rationale here?
> 
> Well, the symbolic link from data/pg_tblspc points to the top directory,
> not to the catalog-version-named subdirectory.  This was done for
> several reasons, particularly so the directory pointed to by the symlink
> would be exactly the same as that specified by CREATE TABLESPACE, for
> code clarity.

Looking at the pg_upgrade code some more, I found that it was not
removing the PG_VERSION file when deleting <= 8.4 tablespace files. 
This might confuse administrators so the attached patch adds the removal
of PG_VERSION.  I would like to apply this to master and 9.0.X.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  2. Re: create tablespace fails silently, or succeeds improperly

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-10-19T02:56:56Z

    Bruce Momjian <bruce@momjian.us> writes:
> Looking at the pg_upgrade code some more, I found that it was not
> removing the PG_VERSION file when deleting <= 8.4 tablespace files. 
> This might confuse administrators so the attached patch adds the removal
> of PG_VERSION.  I would like to apply this to master and 9.0.X.

... why is that a good idea?

			regards, tom lane

  3. Re: create tablespace fails silently, or succeeds improperly

    Bruce Momjian <bruce@momjian.us> — 2010-10-19T03:32:48Z

    Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Looking at the pg_upgrade code some more, I found that it was not
> > removing the PG_VERSION file when deleting <= 8.4 tablespace files. 
> > This might confuse administrators so the attached patch adds the removal
> > of PG_VERSION.  I would like to apply this to master and 9.0.X.
> 
> ... why is that a good idea?

The script already deletes the 8.4 database directories, but leaves
PG_VERSION behind.  Why keep it when all the 8.4 data is gone?  The
script also dates PGDATA for 8.4, so there is nothing left pointing to
that directory.  Here are the delete script file contents after the
patch:

	#!/bin/sh
	
	rm -rf /u/pgsql.old/data
	
	rm -f /rtmp/pgsql/PG_VERSION
	rm -rf /rtmp/pgsql/1
	rm -rf /rtmp/pgsql/11564
	rm -rf /rtmp/pgsql/16384
	rm -rf /rtmp/pgsql/16385
	rm -rf /rtmp/pgsql/27628


-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  4. Re: create tablespace fails silently, or succeeds improperly

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-10-19T14:08:48Z

    Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> Looking at the pg_upgrade code some more, I found that it was not
>>> removing the PG_VERSION file when deleting <= 8.4 tablespace files. 
>>> This might confuse administrators so the attached patch adds the removal
>>> of PG_VERSION.  I would like to apply this to master and 9.0.X.
>> 
>> ... why is that a good idea?

> The script already deletes the 8.4 database directories, but leaves
> PG_VERSION behind.  Why keep it when all the 8.4 data is gone?  The
> script also dates PGDATA for 8.4, so there is nothing left pointing to
> that directory.

Oh, I misunderstood: I thought you were proposing to do this as an
automatic action inside pg_upgrade.  If it's part of the cleanup script,
it's fine.

			regards, tom lane

  5. Re: create tablespace fails silently, or succeeds improperly

    Bruce Momjian <bruce@momjian.us> — 2010-10-19T15:51:15Z

    Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <bruce@momjian.us> writes:
> >>> Looking at the pg_upgrade code some more, I found that it was not
> >>> removing the PG_VERSION file when deleting <= 8.4 tablespace files. 
> >>> This might confuse administrators so the attached patch adds the removal
> >>> of PG_VERSION.  I would like to apply this to master and 9.0.X.
> >> 
> >> ... why is that a good idea?
> 
> > The script already deletes the 8.4 database directories, but leaves
> > PG_VERSION behind.  Why keep it when all the 8.4 data is gone?  The
> > script also dates PGDATA for 8.4, so there is nothing left pointing to
> > that directory.
> 
> Oh, I misunderstood: I thought you were proposing to do this as an
> automatic action inside pg_upgrade.  If it's part of the cleanup script,
> it's fine.

Yes, never automatic.  You can always roll back after pg_upgrade
completes.  Once you start the new server, only then can you not go
back.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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