Re: danger of stats_temp_directory = /dev/shm
От | Alvaro Herrera |
---|---|
Тема | Re: danger of stats_temp_directory = /dev/shm |
Дата | |
Msg-id | 20130820231006.GM6564@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: danger of stats_temp_directory = /dev/shm (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2013-08-19 14:28:28 -0400, Tom Lane wrote: > >> One possibility is to do the initial check somewhere shortly after > >> ChangeToDataDir(), and have the GUC check hook only attempt to make a > >> check in SIGHUP context. Unfortunately we aren't passing the context to > >> check hooks, only GucSource which isn't adequate for this. Not sure if we > >> want to go so far as to change the check-hook API at this point. We could > >> probably think of some other, klugy way to tell if it's initial startup. > > > Is it even actually safe to have stats_temp_directory PGC_SIGHUP after > > the per DB splitup? I haven't audited the code for it, but it seems > > somewhat likely that we would end up with some files in the old and some > > in the new directory? > > That's a good point. For the moment we could just change it to > PGC_POSTMASTER and eliminate this problem. Reducing it back to SIGHUP > would be a future feature, which is evidently less than trivial. Here's a patchset for this. The first patch is the same as upthread, with the enum members renamed; the second is the actual pgstats change. (I considered the idea that checkDirectoryPermissions returned a bitmask of the failed checks, instead of just returning a code for the first check that fails. This might be useful if some caller wants to ignore certain problems. But at the moment I didn't see many other places where this could be used, so it's probably pointless ATM.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: