Re: [Patch] Check file type before calling AllocateFile() for files out of pg data directory to avoid potential issues (e.g. hang). - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [Patch] Check file type before calling AllocateFile() for files out of pg data directory to avoid potential issues (e.g. hang).
Date
Msg-id 10312.1556200162@sss.pgh.pa.us
Whole thread Raw
In response to 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>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: REINDEX INDEX results in a crash for an index of pg_class since9.6
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_dump is broken for partition tablespaces