Re: Strange issue with initdb on 8.0 and Solaris automounts
От | Kenneth Lareau |
---|---|
Тема | Re: Strange issue with initdb on 8.0 and Solaris automounts |
Дата | |
Msg-id | 200501272335.j0RNZfwg007312@minddrive.numenor.org обсуждение исходный текст |
Ответ на | Re: Strange issue with initdb on 8.0 and Solaris automounts (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Strange issue with initdb on 8.0 and Solaris automounts
|
Список | pgsql-hackers |
In message <21723.1106868138@sss.pgh.pa.us>, Tom Lane writes: >"David Parker" <dparker@tazznetworks.com> writes: >> Did initdb previously just assume the -D path existed, and now it is >> trying to create the whole path, if necessary? > >Pre-8.0 it was using mkdir(1), which might possibly contain some weird >workaround for this case on Solaris. > >I suppose that manually creating the data directory before running >initdb would also avoid this issue, since the mkdir(2) loop is only >entered if we don't find the directory in existence. > > regards, tom lane > Actually, creating the 'data' directory first doesn't work either: [delirium:postgres] ~ (17) mkdir data [delirium:postgres] ~ (18) initdb -D /software/postgresql-8.0.0/data The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory /software/postgresql-8.0.0/data ... ok creating directory /software/postgresql-8.0.0/data/global ... initdb: could not create directory "/software/postgresql-8.0.0":Operation not applicable initdb: removing contents of data directory "/software/postgresql-8.0.0/data" Since there's subdirectories that need to be created, it still runs into the problem. I don't know why the command 'mkdir' doesn't exhibit the same problem as the function 'mkdir', but running: mkdir /software/postgresql-8.0.0 produces the correct error "File exists" on my system. I suspect the 'mkdir' command probably checks to see if the directory exists first before trying to create it, which avoids the problem. Ken Lareau elessar@numenor.org
В списке pgsql-hackers по дате отправления: