Re: Re: Sure enough, the lock file is gone
От | Lamar Owen |
---|---|
Тема | Re: Re: Sure enough, the lock file is gone |
Дата | |
Msg-id | 3A7486E8.E382EF8E@wgcr.org обсуждение исходный текст |
Ответ на | Re: Re: Sure enough, the lock file is gone (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Re: Sure enough, the lock file is gone
Re: Re: Sure enough, the lock file is gone |
Список | pgsql-hackers |
Trond Eivind Glomsrød wrote: > > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > It would probably be better if the socket files weren't in /tmp but in > > a postgres-owned directory. However, at this point we have a huge > > backwards compatibility problem to overcome if we want to move the > > socket files. > > Not to sound scheptical, but since when did postgresql care about > backwards compatiblity? Upgrading is already demanding a lot of > knowledge from the user (including needing such information, which > almost no other package do), this is just a minor change (the files > are mostly used by bundled tools - any exceptions?) Upgrading is only one facet of backwards compatibility. When the fe-be protocol was changed for 6.4.2 is a good example. The SQL itself is kept very backwards-compatible, on purpose. Things for backwards-compatibility are not as bad as the upgrading situation would seem to imply. > > There is an option in 7.1 to support defining a different directory > > for the socket files, but I doubt very many people will use it. > I intend to, for the RPMs we ship. Ok, why not fix tmpwatch instead? Only the lock files break FHS -- the sockets can go there by FHS, right? Of course, our requirement that they be in the same location sort of forces the issue. But, 7.1 now touches the locks enought to keep tmpwatch from blowing them out. To where do you intend to move them to? /var/lock/pgsql? /var/run/pgsql? (Or postgresql... I'm still not happy with that change -- the configuration is much nicer, but now the 'postgresql' suffix is fixed -- I'm probably going to have to patch that to pgsql, as I'm already changing many things that I'd prefer to leave closer to what 7.0 had). The change in question is the use of '/usr/share/postgresql' and '/usr/include/postgresql' as part of the installation, rather than allowing '/usr/share/pgsql' and '/usr/include/pgsql' . O well -- I'm just going to have to see how it distills. I've not received any complaints yet, but I expect many after final. :-( -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
В списке pgsql-hackers по дате отправления: