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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: REINDEX INDEX results in a crash for an index of pg_class since9.6
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_dump is broken for partition tablespaces