Re: danger of stats_temp_directory = /dev/shm

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: danger of stats_temp_directory = /dev/shm
Дата
Msg-id 23344.1376936030@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: danger of stats_temp_directory = /dev/shm  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: danger of stats_temp_directory = /dev/shm  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Should we remove "not fast" promotion at all?
Следующее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: Backup throttling