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

From Tom Lane
Subject Re: danger of stats_temp_directory = /dev/shm
Date
Msg-id 23344.1376936030@sss.pgh.pa.us
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  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Alvaro Herrera wrote:
>>> In addition to that, it might be a good idea to do what the comment in the
>>> code suggests, namely do more than zero checking on each file name to try
>>> to make sure it looks like a stats temp file name that we'd generate
>>> before we delete it.  The ownership/permissions test wouldn't be enough
>>> to prevent you from pointing at, say, ~postgres and thereby losing some
>>> files you'd rather not.

>> This seems pretty simple to do; see second attachment.  (It would delete
>> files named, "db_1234.tmpfoobar", that is, valid names with suffixes,
>> but I can't see that being a problem).  (I haven't really tested this
>> part at all.)

> Here's the second attachment.

This looks good except that it can't tell "db_123.statfoo" isn't a match.
The scan limit/buffer size needs to be greater than the longest string
you care about, not only equal to.  I think strcmp not strncmp would be
better coding, too.  Please fix that and commit -- I think this part
is pretty noncontroversial.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Should we remove "not fast" promotion at all?
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: Backup throttling