Re: [HACKERS] flock patch breaks things here
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] flock patch breaks things here |
Дата | |
Msg-id | 16092.904495855@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] flock patch breaks things here (Massimo Dal Zotto <dz@cs.unitn.it>) |
Ответы |
Re: [HACKERS] flock patch breaks things here
|
Список | pgsql-hackers |
Massimo Dal Zotto <dz@cs.unitn.it> writes: > In my opinion the socket and the pidfile should be created in a > directory owned by postgres, for example /tmp/.Pgsql-unix, like does X. The pidfile belongs at the top level of the database directory (eg, /usr/local/pgsql/data/postmaster.pid), because what it actually represents is that there is a postmaster running *for that database group*. If you want to support multiple database sets on one machine (which I do), then the interlock has to be per database directory. Putting the pidfile into a common directory would mean we'd have to invent some kind of pidfile naming convention to keep multiple postmasters from tromping on each other. This is unnecessarily complex. I agree with you that putting the socket file into a less easily munged directory than /tmp would be a good idea for security. But that's a separate issue. On machines that understand stickybits for directories, the security hole is not really very big. At this point, the fact that /tmp/.s.PGSQL.port# is the socket path is effectively a version-independent aspect of the FE/BE protocol, and so we can't change it without breaking old applications. I'm not sure that that's worth the security improvement. What I'd like to see someday is a postmaster command line switch to tell it to use *only* TCP connections and not create a Unix socket at all. That hasn't been possible so far, because we were relying on the socket file to provide a safety interlock against starting multiple postmasters. But an interlock using a pidfile would be much better. (Look around; *every* other Unix daemon I know of that wants to ensure that there's only one of it uses a pidfile interlock. Not file locking. There's a reason why that's the well-trodden path.) regards, tom lane
В списке pgsql-hackers по дате отправления: