Обсуждение: Re: [HACKERS] postmaster locking issues.

Поиск
Список
Период
Сортировка

Re: [HACKERS] postmaster locking issues.

От
"Thomas G. Lockhart"
Дата:
> >> 5.  The port lock will be kept in '/var/opt/pgsql/lock/'.

As everyone has pointed out, we can't count on a specific convention for
where the lock file should go. However, we can probably count on a
convention to be followed on a particular OS. That would seem to be
something to define in Makefile.port, which could then be overridden by
a configure option or Makefile.custom entry.

On my RedHat Linux systems, the appropriate place seems to be /var/lock
or /var/lock/pgsql.

                        - Tom

Re: [HACKERS] postmaster locking issues.

От
Bruce Momjian
Дата:
> > >> 5.  The port lock will be kept in '/var/opt/pgsql/lock/'.
>
> As everyone has pointed out, we can't count on a specific convention for
> where the lock file should go. However, we can probably count on a
> convention to be followed on a particular OS. That would seem to be
> something to define in Makefile.port, which could then be overridden by
> a configure option or Makefile.custom entry.
>
> On my RedHat Linux systems, the appropriate place seems to be /var/lock
> or /var/lock/pgsql.

I have talked to Billy.  I see no real value to try chasing around
OS-specific lock file locations.  /tmp is fine, and if they don't have
sticky bits in /tmp, they have much larger problems than the location of
the lock file.

--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


Re: [HACKERS] postmaster locking issues.

От
"Thomas G. Lockhart"
Дата:
> I have talked to Billy.  I see no real value to try chasing around
> OS-specific lock file locations.  /tmp is fine, and if they don't have
> sticky bits in /tmp, they have much larger problems than the location
> of the lock file.

The OS-specific areas would be a nice feature, but not for this release
of course. We could either put in the hooks to specify the area now, and
default to /tmp, or we could put that off until December.

Perhaps Billy and I can work it through then...

                       - Tom

Re: [HACKERS] postmaster locking issues.

От
Bruce Momjian
Дата:
> > I have talked to Billy.  I see no real value to try chasing around
> > OS-specific lock file locations.  /tmp is fine, and if they don't have
> > sticky bits in /tmp, they have much larger problems than the location
> > of the lock file.
>
> The OS-specific areas would be a nice feature, but not for this release
> of course. We could either put in the hooks to specify the area now, and
> default to /tmp, or we could put that off until December.
>
> Perhaps Billy and I can work it through then...

Yes, let's wait.  I don't want another round of 'My OS has ...' at this
point in the release cycle.  I think Marc would have a heart attack.

--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


Re: [HACKERS] postmaster locking issues.

От
"Marc G. Fournier"
Дата:
On Mon, 12 Oct 1998, Thomas G. Lockhart wrote:

> > >> 5.  The port lock will be kept in '/var/opt/pgsql/lock/'.
>
> As everyone has pointed out, we can't count on a specific convention for
> where the lock file should go. However, we can probably count on a
> convention to be followed on a particular OS. That would seem to be
> something to define in Makefile.port, which could then be overridden by
> a configure option or Makefile.custom entry.
>
> On my RedHat Linux systems, the appropriate place seems to be /var/lock
> or /var/lock/pgsql.

    FreeBSD has a /var/spool/lock...Solaris has /var/spool/locks

    Hrmmmm...there are a couple of ways of doing this...we could put
it into the template for the OS as a -DLOCK_DIR="", which would probably
be the simplist (instead of having configure searching all
possibilities)...

Marc G. Fournier                               scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org                       ICQ#7615664


Re: [HACKERS] postmaster locking issues.

От
"Marc G. Fournier"
Дата:
On Mon, 12 Oct 1998, Bruce Momjian wrote:

> > > >> 5.  The port lock will be kept in '/var/opt/pgsql/lock/'.
> >
> > As everyone has pointed out, we can't count on a specific convention for
> > where the lock file should go. However, we can probably count on a
> > convention to be followed on a particular OS. That would seem to be
> > something to define in Makefile.port, which could then be overridden by
> > a configure option or Makefile.custom entry.
> >
> > On my RedHat Linux systems, the appropriate place seems to be /var/lock
> > or /var/lock/pgsql.
>
> I have talked to Billy.  I see no real value to try chasing around
> OS-specific lock file locations.  /tmp is fine, and if they don't have
> sticky bits in /tmp, they have much larger problems than the location of
> the lock file.

    I personally do not like putting stuff like that into /tmp.../tmp,
IMHO, is such that if i need to, I can run 'find /tmp -mtime +1 -exec rm
{} \;" without feeling a twinge of worry or guilt...putting lock and/or
pid files in there is just plain *wrong*...

Marc G. Fournier                               scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org                       ICQ#7615664


Re: [HACKERS] postmaster locking issues.

От
"Thomas G. Lockhart"
Дата:
> > On my RedHat Linux systems, the appropriate place seems to be
> > /var/lock or /var/lock/pgsql.
> FreeBSD has a /var/spool/lock...Solaris has /var/spool/locks
> we could put it into the template for the OS as a -DLOCK_DIR="", which
> would probably be the simplist (instead of having configure searching
> all possibilities)...

I like this. And one can override it with Makefile.custom if desired.

There are other items appearing in some of the Makefiles which would do
better to go in the templates. In particular, some of the library
Makefiles have big chunks of "ifeq ($(PORTNAME), xxx)" code containing
lots of duplicate or repetative info. We can/should move all of this
stuff out into the templates and into configure.

Something to do for v6.5...

                     - Tom