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