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 | 10312.1556200162@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). (Paul Guo <pguo@pivotal.io>) |
Список | pgsql-hackers |
Paul Guo <pguo@pivotal.io> writes: > On Wed, Apr 24, 2019 at 10:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Alvaro Herrera <alvherre@2ndquadrant.com> writes: >>> 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? > I'm not sure if those hardcoded temp filenames (not just those in pgstat) > are used across postgres reboot. > If no, we should instead call glibc function to create unique temp files > and also remove those hardcode temp > filename variables, else we also might want them to be regular files. I do not see any actual need to change anything here. Note that the whole business might look quite different by next year or so, if the shmem-based stats collector patch gets merged. So I'm hesitant to throw unnecessary changes into that code right now anyway --- it'd just break that WIP patch. But in any case, the stats directory is a PG private directory, and just like everything else inside $PGDATA, it is very much "no user-serviceable parts inside". Anybody sticking a FIFO (or anything else) in there had better be a developer with some quite specific debugging purpose in mind. So I don't see a reason for file type checks in pgstat, any more than we have them for, say, relation data files. regards, tom lane
В списке pgsql-hackers по дате отправления: