Re: danger of stats_temp_directory = /dev/shm
От | Tom Lane |
---|---|
Тема | Re: danger of stats_temp_directory = /dev/shm |
Дата | |
Msg-id | 27252.1376941876@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: danger of stats_temp_directory = /dev/shm (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: danger of stats_temp_directory = /dev/shm
|
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: > Tom, >> I note BTW that similar complaints could be lodged against the >> log_directory setting. We've not worried about that one too much. > Actually, it does happen that when you change log_directory on a reload, > stuff takes an uneven amount of time to "cut over"; that is, there's a > few seconds while you're writing to both logs at once. Materially, > though, this isn't a serious operational issue (the logs are known to be > asynchronous), so beyond confusing newbies, it's not something we'd want > to fix. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: