postmaster locking issues.
After looking into the issue of using PID file locks vs. flock/unlock, I have
come to the following conclusions:
1. It is generally agreed that a PID lock file should replace the current me-
thod of locking (fcntl based locking). (See the message thread with
'[HACKERS] flock patch breaks things here' in the subject).
2. The purpose of the lock file is to prevent multiple postmasters from run-
ning on the same port and database.
3. Two PID files will be necessary, one to prevent mulitple instances of post-
masters from running against the same data base, and one to prevent
multiple
instances from using the same port.
4. The database lock will be located in the DATA directory being locked.
5. The port lock will be kept in '/var/opt/pgsql/lock/'.
Comments, questions, concerns?
--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |
After looking into the issue of using PID file locks vs. flock/unlock, I have
come to the following conclusions:1. It is generally agreed that a PID lock file should replace the current me-
thod of locking (fcntl based locking). (See the message thread with
'[HACKERS] flock patch breaks things here' in the subject).2. The purpose of the lock file is to prevent multiple postmasters from run-
ning on the same port and database.3. Two PID files will be necessary, one to prevent mulitple instances of post-
masters from running against the same data base, and one to prevent
multiple
instances from using the same port.4. The database lock will be located in the DATA directory being locked.
5. The port lock will be kept in '/var/opt/pgsql/lock/'.
Yes, except lock file should be kept in /tmp. I don't have
/var/opt/..., and I doubt others do either.
--
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
5. The port lock will be kept in '/var/opt/pgsql/lock/'.
Wouldn't the bind() call fail for one of the postmasters if they both try to
use the same port?
Taral
On Sat, 10 Oct 1998, Bruce Momjian wrote:
After looking into the issue of using PID file locks vs. flock/unlock, I have
come to the following conclusions:1. It is generally agreed that a PID lock file should replace the current me-
thod of locking (fcntl based locking). (See the message thread with
'[HACKERS] flock patch breaks things here' in the subject).2. The purpose of the lock file is to prevent multiple postmasters from run-
ning on the same port and database.3. Two PID files will be necessary, one to prevent mulitple instances of post-
masters from running against the same data base, and one to prevent
multiple
instances from using the same port.4. The database lock will be located in the DATA directory being locked.
5. The port lock will be kept in '/var/opt/pgsql/lock/'.
Yes, except lock file should be kept in /tmp. I don't have
/var/opt/..., and I doubt others do either.
My RedHat system doesn't have /var/opt either. I'd agree with /tmp as
that's been in every unix style system I've used so far.
--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
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
Import Notes
Reference msg id not found: 26765.908115320@sss.pgh.pa.us | Resolved by subject fallback
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 19026I 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
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 19026I strongly disagree. If we wish postgresql to please people, we do not want
to start out by annoying them with the install. Specifically, some of us
(I happen to be one), feel that the FHS is important and that packages
should follow it.Also, /tmp is a security risk. Why make it harder for someone trying to
use postgresql, say for a real application involving money or confidential
information or something, to run a tightly nailed down system.This item should follow platform convention by default (ie, FHS on Linux
and other "progressive" systems) but be configurable at install time.
OK, I agree, we should allow locks to be placed wherever people want
them, and the periodic cleaning of /tmp is a good argument.
Perhaps, rather than using OS-specific stuff, we can just test from
configure for various directories that are writeable, and choose the
best one. That seems nicer to me, and fewer configuration headaches.
I assume this would apply to lock and socket files? If so, each client
for unix-domain sockets would have to know about the location chosen at
configure time. That sounds messy. I am adding this item to the
TODO/Open Items list.
--
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 19026Import Notes
Reply to msg id not found: 9810121550.AA16802@hawk.oak.informix.com | Resolved by subject fallback
Why not just create a ~postgres/locks directory and place the
socket file and postmaster locks there. Then we could place a
lock in each DATA directory signifing the pid of the postmaster
that contains the lock?
Matt
I strongly disagree. If we wish postgresql to please people, we do not want
to start out by annoying them with the install. Specifically, some of us
(I happen to be one), feel that the FHS is important and that packages
should follow it.Also, /tmp is a security risk. Why make it harder for someone trying to
use postgresql, say for a real application involving money or confidential
information or something, to run a tightly nailed down system.This item should follow platform convention by default (ie, FHS on Linux
and other "progressive" systems) but be configurable at install time.OK, I agree, we should allow locks to be placed wherever people want
them, and the periodic cleaning of /tmp is a good argument.Perhaps, rather than using OS-specific stuff, we can just test from
configure for various directories that are writeable, and choose the
best one. That seems nicer to me, and fewer configuration headaches.I assume this would apply to lock and socket files? If so, each client
for unix-domain sockets would have to know about the location chosen at
configure time. That sounds messy. I am adding this item to the
TODO/Open Items list.-- 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
----------
Matthew C. Aycock
Operating Systems Analyst/Admin, Senior
Dept Math/CS
Emory University, Atlanta, GA
Internet: matt@mathcs.emory.edu
Import Notes
Resolved by subject fallback
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
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
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