Re: [Patch] Check file type before calling AllocateFile() for filesout of pg data directory to avoid potential issues (e.g. hang).
От | Andres Freund |
---|---|
Тема | Re: [Patch] Check file type before calling AllocateFile() for filesout of pg data directory to avoid potential issues (e.g. hang). |
Дата | |
Msg-id | 20190424044931.zfcv7k723ebdmenj@alap3.anarazel.de обсуждение исходный текст |
Ответ на | [Patch] Check file type before calling AllocateFile() for files outof pg data directory to avoid potential issues (e.g. hang). (Paul Guo <pguo@pivotal.io>) |
Ответы |
Re: [Patch] Check file type before calling AllocateFile() for filesout of pg data directory to avoid potential issues (e.g. hang).
|
Список | pgsql-hackers |
Hi, On 2019-04-24 12:46:15 +0800, Paul Guo wrote: > This is, in theory, not a 100% bug, but it is probably not unusual to see > conflicts of files between postgresql sqls and other applications on the > same node so I think the fix is needed. I checked all code that calls > AllocateFile() and wrote a simple patch to do sanity check (if the file > exists it must be a regular file) for those files which are probably out of > the postgres data directories which we probably want to ignore. This is > actually not a perfect fix since it is not atomic (check and open), but it > should fix most of the scenarios. To be perfect, we might want to refactor > AllocateFile() to allow atomic check&create using either 'x' in fopen() > or O_EXCL in open(), also it seems that we might not want to create temp > file for AllocateFile() with fixed filenames. This is beyond of this patch > of course. This seems like a bad idea to me. IMO we want to support using a pipe etc here. If the admin creates a fifo like this without attaching a program it seems like it's their fault. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: