Robert Haas <robertmh...@gmail.com> writes: > On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian <br...@momjian.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers