Re: create tablespace fails silently, or succeeds improperly

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