Re: create tablespace fails silently, or succeeds improperly
От | Robert Haas |
---|---|
Тема | Re: create tablespace fails silently, or succeeds improperly |
Дата | |
Msg-id | AANLkTiku4sp15V0kgaFZzP+xDVZTRyZdOLDWXNGDAD6Y@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: create tablespace fails silently, or succeeds improperly (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: create tablespace fails silently, or succeeds
improperly
Re: create tablespace fails silently, or succeeds improperly |
Список | pgsql-hackers |
On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian <bruce@momjian.us> wrote: > Robert Haas wrote: >> On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > Bruce Momjian <bruce@momjian.us> writes: >> >> Robert Haas wrote: >> >>> Perhaps we should fix the behavior rather than the documentation. >> > >> >> We can't fix the behavior because we have to allow an old cluster to >> >> keep its tablespace files during a pg_upgrade. ?They are given a script >> >> to delete those files later, if they want. >> > >> > The new *layout* of the files may be forced by pg_upgrade >> > considerations, but I don't think that proves much of anything about >> > ownership and permissions settings --- especially not the fact that we >> > are now enforcing settings that were designed for the data directory >> > itself on what is effectively one level up from that. >> >> 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: