Re: pgsql: Fix failure to check for open() or fsync() failures.
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: pgsql: Fix failure to check for open() or fsync() failures. |
| Дата | |
| Msg-id | 2389.1545877849@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: pgsql: Fix failure to check for open() or fsync() failures. (Michael Paquier <michael@paquier.xyz>) |
| Список | pgsql-hackers |
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Dec 26, 2018 at 08:35:22PM -0500, Tom Lane wrote:
>> Oh, I see. Yeah, if we're ignoring errors anyway, the stat calls
>> seem redundant.
> For this one, I think that we could simplify as attached (this causes
> open() to fail additionally because of the sync flags, but that's not
> really worth worrying). Thoughts?
Actually, now that I think a bit more, this isn't a good idea. We want
standby_signal_file_found (resp. recovery_signal_file_found) to get set
if the file exists, even if we're unable to fsync it for some reason.
A counterexample to the proposed patch is that a signal file that's
read-only to the server will get ignored, which it should not be.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера