Re: danger of stats_temp_directory = /dev/shm - Mailing list pgsql-hackers

From Andres Freund
Subject Re: danger of stats_temp_directory = /dev/shm
Date
Msg-id 20130819190648.GB26775@awork2.anarazel.de
Whole thread Raw
In response to Re: danger of stats_temp_directory = /dev/shm  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: danger of stats_temp_directory = /dev/shm
List pgsql-hackers
On 2013-08-19 13:50:38 -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> 
> > I think we should change 9.3 to be restrictive about ownership/permissions
> > on the stats_temp_directory (ie, require owner = postgres user,
> > permissions = 0700, same as for the $PGDATA directory).
> 
> Not an easy thing to do, this.  It should be done as a GUC check hook,
> ISTM, but this doesn't work because the first time those are run we
> haven't yet changed to the data directory, and so any relative path
> (which the default value is) will cause the check to fail (I *assume*
> setting an absolute path would work, but I haven't tried).  We could
> skip the check on the first run, and verify the directory separately in
> PostmasterMain() after changing CWD, but I don't see any way to detect
> that we're in the initial run of GUC processing.  Any thoughts?  Maybe
> the idea of using a GUC check hook is flawed, but I don't think so
> because we also need to verify a directory when the setting changes on
> SIGHUP.

Hm. Is a check like that actually sufficient? The idea of setting
stats_temp_directory to /dev/shm/postgres or similar in all of several
clusters on one machine doesn't seem to be that far fetched.

The only idea I have to prevent that is writing some minimal pg_control
like file into the temp stats directory iff it's empty. Then, when
reusing a stats temp directory, refuse to work unless it has the same
ids.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: [GENERAL] currval and DISCARD ALL
Next
From: Andres Freund
Date:
Subject: Re: Backup throttling