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: Stephen Frost <sfrost(at)snowman(dot)net>, 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-12-11 18:38:28
Message-ID: 18308.1292092708@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm not really thinking about crash recovery, but replication slaves.
>> Omitting to create the tablespace location directories on slaves
>> doesn't seem far-fetched at all. Of course, it's likely that
>> the slave server will lack permissions to create in the location
>> directory's parent; but if it can, the outcome shouldn't be too
>> unreasonable.

> Creating the tablespace directory itself would be reasonable, but
> recursing all the way up seems dubious.

Well, it's *very* unlikely that the slave server would have permissions
to create in the root directory or close to it.  If you grant that it's
reasonable to create the location directory itself, why not the parent
too, if that's still in a directory that's writable?  I agree that the
reasonableness of the behavior drops off the more you go up, but so does
the probability of having the needed permissions.  I don't agree that
it's a binary choice where creating exactly one directory is reasonable
but exactly two isn't.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: tvDate: 2010-12-11 18:58:53
Subject: keeping a timestamp of the last stats reset (for a db, table and function)
Previous:From: Robert HaasDate: 2010-12-11 18:23:10
Subject: Re: create tablespace fails silently, or succeeds improperly

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