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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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


Browse pgsql-hackers by date

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