Re: create tablespace fails silently, or succeeds improperly
От | Robert Haas |
---|---|
Тема | Re: create tablespace fails silently, or succeeds improperly |
Дата | |
Msg-id | AANLkTim2oR98yBxBdjcWGjMqzVfxPLkdKFC9kVHKF=CV@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: create tablespace fails silently, or succeeds improperly (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, Dec 11, 2010 at 1:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane <tgl@sss.pgh.pa.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. I'm just giving you my opinion. Take it for what it's worth. :-) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: