Re: [Patch] Check file type before calling AllocateFile() for files out of pg data directory to avoid potential issues (e.g. hang).
От | Tom Lane |
---|---|
Тема | Re: [Patch] Check file type before calling AllocateFile() for files out of pg data directory to avoid potential issues (e.g. hang). |
Дата | |
Msg-id | 11717.1556116563@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [Patch] Check file type before calling AllocateFile() for filesout of pg data directory to avoid potential issues (e.g. hang). (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [Patch] Check file type before calling AllocateFile() for filesout of pg data directory to avoid potential issues (e.g. hang).
Re: [Patch] Check file type before calling AllocateFile() for filesout of pg data directory to avoid potential issues (e.g. hang). |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > On 2019-Apr-24, Paul Guo wrote: >> On Wed, Apr 24, 2019 at 12:49 PM Andres Freund <andres@anarazel.de> wrote: >>> 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. >> Oh, I never know this application scenario before. So yes, for this, we >> need to keep the current code logic in copy code. > But the pgstat.c patch seems reasonable to me. Nah, I don't buy that one either. Nobody has any business creating any non-Postgres files in the stats directory ... and if somebody does want to stick a FIFO in there, perhaps for debug purposes, why should we stop them? The case with COPY is a bit different, since there it's reasonable to be worried about collisions with other users' files --- but I agree with Andres that this change would eliminate too many valid use-cases. regards, tom lane
В списке pgsql-hackers по дате отправления: