Re: danger of stats_temp_directory = /dev/shm
От | Andres Freund |
---|---|
Тема | Re: danger of stats_temp_directory = /dev/shm |
Дата | |
Msg-id | 20130819200034.GH26775@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: danger of stats_temp_directory = /dev/shm (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: danger of stats_temp_directory = /dev/shm
|
Список | pgsql-hackers |
On 2013-08-19 15:51:16 -0400, Tom Lane wrote: > 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. Won't it possibly cause stats being entirely lost? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: