Re: fsync-pgdata-on-recovery tries to write to more files than previously
В списке pgsql-hackers по дате отправления:
| От | Christoph Berg |
|---|---|
| Тема | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
| Дата | |
| Msg-id | 20150529185945.GA15185@msg.df7cb.de обсуждение исходный текст |
| Ответ на | Re: fsync-pgdata-on-recovery tries to write to more files than previously (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Re: Tom Lane 2015-05-29 <13871.1432921756@sss.pgh.pa.us> > Why can't the user stop it? We won't be bleating about the case of a > symlink to a non-writable file someplace else, which is the Debian use > case. I don't see a very good excuse to have a non-writable file right > in the data directory. I've repeatedly seen PGDATA or pg_xlog been put directly on a mountpoint, which means there well be a non-writable lost+found directory there. (A case with pg_xlog was also reported as a support case at credativ.) I'm usually advising against using the top level directory directly, but it's not uncommon to encounter it. > In any case, if the cost of such a file is one more line of log output > during a crash restart, most people would have no problem at all in > ignoring that log output. Nod. Christoph -- cb@df7cb.de | http://www.df7cb.de/
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера