Re: F_SETLK is looking worse and worse...
От | Peter Eisentraut |
---|---|
Тема | Re: F_SETLK is looking worse and worse... |
Дата | |
Msg-id | Pine.LNX.4.21.0011291731510.796-100000@peter.localdomain обсуждение исходный текст |
Ответ на | F_SETLK is looking worse and worse... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: F_SETLK is looking worse and worse...
|
Список | pgsql-hackers |
Tom Lane writes: > I can only think of one scenario where this is worse than what we have > now: if someone is running a /tmp-directory-sweeper that is bright > enough not to remove socket files, it would still zap the interlock > file, thus potentially allowing a second postmaster to take over the > socket file. This doesn't seem like a mainstream problem though. Red Hat by default cleans out all files under /tmp and subdirectories that haven't been accesses for 10 days. I assume other Linux distributions do similar things. Red Hat's tmpwatch doesn't ever follow symlinks, though. That means you could make /tmp/.s.PGSQL.5432.lock a symlink to PGDATA/postmaster.pid. That might be a good idea in general, since establishes an easy to examine correspondence between data directory and port number. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: