Re: create tablespace fails silently, or succeeds improperly
От | Robert Haas |
---|---|
Тема | Re: create tablespace fails silently, or succeeds improperly |
Дата | |
Msg-id | AANLkTi==B2-0dZhjM=hp0oUxFz3z=3b0outXojC56sO6@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: create tablespace fails silently, or succeeds improperly (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: create tablespace fails silently, or succeeds improperly
|
Список | pgsql-hackers |
On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Stephen Frost <sfrost@snowman.net> writes: >> * Robert Haas (robertmhaas@gmail.com) wrote: >>> On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> Anybody have a problem with adopting this behavior? > >>> Seems a bit surprising. > >> Yeahh.. I'm not really sure about mkdir -p type actions from a SQL >> command. Not entirely sure why but it doesn't feel 'right' to me. I'd >> rather have PG complain "that directory doesn't exist". > > OK. Is there any value in doing mkdir -p in WAL-recovery execution of > CREATE TABLESPACE but not regular execution? I don't think so. If someone creates a directory that is not fsync'd, and then creates a subdirectory and puts a tablespace on it, and then crashes after this has been WAL-logged but before the directory entries have hit the disk, well, unlucky for them, but that's a vanishingly rare situation. There's no guarantee that we'd set properties on the parent directory that would match the user's expectation anyway, especially if SE-Linux or something is involved. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: