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 по дате отправления: