Re: danger of stats_temp_directory = /dev/shm

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: danger of stats_temp_directory = /dev/shm
Дата
Msg-id 28615.1376943157@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: danger of stats_temp_directory = /dev/shm  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-08-19 15:51:16 -0400, Tom Lane wrote:
>> Yeah, the stats temp directory will act pretty much the same way: there
>> will be an interval where backends might not get the most up-to-date data,
>> but it's not clear that it's worth the trouble to get it to be more nearly
>> synchronous.

> Won't it possibly cause stats being entirely lost?

How would that happen?  The directory is write-only as far as the stats
collector is concerned, no?

Admittedly it might take a long time for it to write out the data again
for some database that wasn't getting any updates.  Possibly it'd be worth
teaching the SIGHUP code segment in the stats collector to check for a
change in the value of stats_temp_directory and schedule write-out for all
databases if that happens.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: UNNEST with multiple args, and TABLE with multiple funcs
Следующее
От: Christophe Pettus
Дата:
Сообщение: ereport documentation patch