Skip site navigation (1) Skip section navigation (2)

Re: create tablespace fails silently, or succeeds improperly

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Dave Cramer <pg(at)fastcrypt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: create tablespace fails silently, or succeeds improperly
Date: 2010-10-18 19:21:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Robert Haas wrote:
>>> I haven't yet been convinced we need or want to relax the rule about
>>> the directory being empty.
>> Uh, how would pg_upgrade work then? It would require renaming the
>> top-level tablespace directory, which might require root permissions.

> Huh?  Whether or not we choose to store our data files in a
> subdirectory is an independent question from whether or not we verify
> that the directory is empty before we start scribbling on it.

No, you're missing the point.  If a pre-9.0 DB is told that tablespace T
has location '/foo/bar', it'll start creating stuff right in /foo/bar.
pg_upgrade will tell 9.0 to create the tablespace with location /foo/bar
as well.  If 9.0 refuses because that directory contains stuff already,
the upgrade will fail.  Instead, we make a version-numbered subdirectory
and start creating 9.0's stuff there.

Given the use of the version-numbered subdirectory, I see no real merit
in insisting that the parent directory be empty anyway.  It'd be
precisely analogous to "initdb -D /foo/bar/data" insisting that /foo/bar
be empty, which we have never done and nobody's ever suggested would be
a good idea.

What *should* be tested, and I hope is, is that if the version-numbered
subdirectory already exists then it be empty.  Or do we just reject the
create whenever the subdirectory exists already?  That seems like a bad
idea for the same reasons that we allow initdb on an existing data
directory: sometimes it's impractical to open up the permissions on the
parent directory for exactly the window needed to issue the creation
command.  I think we should be testing for empty and then putting a
PG_VERSION file in it to convert it to nonempty ... which doesn't seem
to be happening now.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Jeff DavisDate: 2010-10-18 19:24:56
Subject: Re: Floating-point timestamps versus Range Types
Previous:From: Andres FreundDate: 2010-10-18 19:17:24
Subject: Re: Creation of temporary tables on read-only standby servers

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group