Re: Re: Sure enough, the lock file is gone
От | teg@redhat.com (Trond Eivind Glomsrød) |
---|---|
Тема | Re: Re: Sure enough, the lock file is gone |
Дата | |
Msg-id | xuy1ytnz3k3.fsf@halden.devel.redhat.com обсуждение исходный текст |
Ответ на | Re: Re: Sure enough, the lock file is gone (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Sure enough, the lock file is gone
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > teg@redhat.com (Trond Eivind Glomsrød) writes: > > Ideally, the locks should be in /var/lock/pgsql and the socket > > somewhere else - like /var/lib/pgsql (our mysql packages do this, and > > both of them are specified in /etc/my.cnf). (note that you AFAIK (I don't use mysql much, I prefer postgresql) can have multiple sections if you want want to have multiple backends running. > That is not "ideal", in fact it would break one of the specific features > that UUNET asked us for. Namely, to be able to have noninterfering > sets of socket files in different explicitly-specified directories. > If the lock files don't live where the sockets do, then this doesn't > work. I don't see why this must be so... > > Explictly, yes. However, FHS says /tmp is for temporary files. Also, > > it says programs shouldn't count on data to be stored there between > > invocations. 10+ days isn't temporary... > > We aren't counting on data to be stored in /tmp "between invocations". Between invocations of client programs. You're using /tmp as a shared of stored data. -- Trond Eivind Glomsrød Red Hat, Inc.
В списке pgsql-hackers по дате отправления: