| От | Andrew Dunstan |
|---|---|
| Тема | Re: Lockfile restart failure is still there :-( |
| Дата | |
| Msg-id | 423A0BF4.8090202@dunslane.net обсуждение исходный текст |
| Ответ на | Lockfile restart failure is still there :-( (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Tom Lane wrote:
>But I evidently didn't
>read the code quite carefully enough: as CreateLockFile() is written,
>it considers an EPERM error from kill() to be reason to treat the
>lockfile as valid.
>
>
I thought that was part of what you were going to address. There can
hardly be an objection now to fixing it.
>I am strongly tempted to add a direct check in checkDataDir() that the
>data directory actually does belong to our own uid, just for paranoia's
>sake. Someone might decide that they could relax the permission check
>("hey, why not let the dbadmin group have write permission on $PGDATA")
>without realizing they'd be weakening the startup safety interlock.
>
>
>
>
I assume that ACLs can't be used to get around the restrictions ...
cheers
andrew
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера