Re: Why isn't stats_temp_directory automatically created?
От | Bruce Momjian |
---|---|
Тема | Re: Why isn't stats_temp_directory automatically created? |
Дата | |
Msg-id | 201002260243.o1Q2hi003300@momjian.us обсуждение исходный текст |
Ответ на | Re: Why isn't stats_temp_directory automatically created? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Why isn't stats_temp_directory automatically created?
|
Список | pgsql-hackers |
I assume we decided we didn't want this. --------------------------------------------------------------------------- Tom Lane wrote: > Fujii Masao <masao.fujii@gmail.com> writes: > > Here is the revised patch; If stats_temp_directory indicates the symlink, > > we pursue the chain of symlinks and create the referenced directory. > > I looked at this patch a bit. I'm still entirely unconvinced that we > should be doing this at all --- if the directory is not there, there's > a significant probability that there's something wrong that is beyond > the backend's ability to understand or correct. However, even ignoring > that objection, the patch is not ready to commit for a number of > reasons: > > * Repeating the operation every time the stats file is written doesn't > seem like a particularly good idea; it eats cycles, and if the directory > disappears during live operation then there is *definitely* something > fishy going on. Can't we fix it so that the work is only done when the > path setting changes? (In principle you could do it in > assign_pgstat_temp_directory(), but I think something would be needed to > ensure that only the stats collector process actually tries to create > the directory. Or maybe it would be simplest to try to run the code only > when we get a failure from trying to create the stats temp file.) > > * I don't think the mkdir_p code belongs in fd.c. It looks like > you copied-and-pasted it from initdb.c, which isn't any good either; > we don't want to maintain multiple copies of this. Maybe a new > src/port/ file is indicated. > > * elog(LOG) is not exactly an adequate response if the final chdir fails > --- you have just broken the process beyond recovery. That alone may be > sufficient reason to reject the attempt to deal with symlinks. As far > as pgstat_temp_directory is concerned, I'm not sure of the point of > making the GUC point to a symlink anyway --- if you have a GUC why not > just point it where you want the directory to be? > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive,Christ can be your backup. +
В списке pgsql-hackers по дате отправления: