> All of these lock functions succeed when the same process asks for a
> lock that it already has. That is:
>
> fcntl(fd, ...);
> fcntl(fd, ...); /* success -- no error returned */
>
> For flock() only, the lock is inherited by a child process along
> with the file descriptor so the ch
> That same documentation mentions that locks acquired using flock()
> will *not* invoke the mandatory lock semantics even if on a file
> marked for it, so I guess flock() isn't implemented on top of fcntl()
> in Linux.
They're not. And there's another difference between fcntl and flock in
Linux:
Tom Lane wrote:
> On HPUX 10.20, flock doesn't seem to exist (hasn't got a man page nor
> any mention in /usr/include).
Correct. Still isn't there in later releases.
> lockf says
>
> All locks for a process are released upon
> the first close of the file, even if the process still
Curt Sampson <[EMAIL PROTECTED]> wrote:
> On Sun, 2 Feb 2003, Tom Lane wrote:
>
> > This all doesn't look good for using file locks in the way I had in
> > mind :-( ... but considering that all these man pages seem pretty vague,
> > maybe some direct experimentation is called for.
>
> Definitel
On Sun, 2 Feb 2003, Tom Lane wrote:
> This all doesn't look good for using file locks in the way I had in
> mind :-( ... but considering that all these man pages seem pretty vague,
> maybe some direct experimentation is called for.
Definitely. I wonder about the NetBSD manpage quotes in the post
Giles Lean <[EMAIL PROTECTED]> writes:
> Boring reference material follows.
Couldn't help noticing that you omitted HPUX ;-)
On HPUX 10.20, flock doesn't seem to exist (hasn't got a man page nor
any mention in /usr/include). lockf says
All locks for a process are released upon
the fir
Curt Sampson <[EMAIL PROTECTED]> wrote:
> At any rate, it seems to me highly unlikely that, since the child has
> the *same* descriptor as the parent had, that the lock would
> disappear.
It depends on the lock function. After fork():
o with flock() the lock continues to be held, but will
On Fri, 31 Jan 2003, Tom Lane wrote:
> Antti Haapala <[EMAIL PROTECTED]> writes:
> > And from SunOS 5.8 flock
> > Locks are on files, not file descriptors. That is, file
> > descriptors duplicated through dup(2) or fork(2) do not
> > result in multiple instances of a lock,
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > So if we wanted to make use of mandatory locks, we'd have to refrain
> > from using flock().
>
> We have no need for mandatory locks; the advisory style will do fine.
> This is true because we have no desire to interoperate with any
> n
Kevin Brown <[EMAIL PROTECTED]> writes:
> So if we wanted to make use of mandatory locks, we'd have to refrain
> from using flock().
We have no need for mandatory locks; the advisory style will do fine.
This is true because we have no desire to interoperate with any
non-Postgres code ... everyone
Curt Sampson wrote:
> On Fri, 31 Jan 2003, Shridhar Daithankar<[EMAIL PROTECTED]> wrote:
>
> > Besides file locking is implemented using setgid bit on most unices. And
> > everybody is free to do what he/she thinks right with it.
>
> I don't believe it's implemented with the setgid bit on most U
On Fri, 31 Jan 2003, Shridhar Daithankar<[EMAIL PROTECTED]> wrote:
> Besides file locking is implemented using setgid bit on most unices. And
> everybody is free to do what he/she thinks right with it.
I don't believe it's implemented with the setgid bit on most Unices. As
I recall, it's certain
Antti Haapala <[EMAIL PROTECTED]> writes:
> And from SunOS 5.8 flock
> Locks are on files, not file descriptors. That is, file
> descriptors duplicated through dup(2) or fork(2) do not
> result in multiple instances of a lock, but rather multiple
> references to a sin
> But this only wins if a child process inheriting an open file also
> inherits copies of any locks held by the parent. If not, then the
> issue is moot. Anybody have any idea if file locks work that way?
> Is it portable??
>From RedHat 8.0 manages fork(2):
SYNOPSIS
#include
#in
Tom Lane wrote:
> But this only wins if a child process inheriting an open file also
> inherits copies of any locks held by the parent. If not, then the
> issue is moot. Anybody have any idea if file locks work that way?
> Is it portable??
An alternate way might be to use semaphores, but I can't
On Friday 31 Jan 2003 9:56 am, you wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> But this only wins if a child process inheriting an open file also
> inherits copies of any locks held by the parent. If not, then the
> issue is moot. Anybody have any idea if file locks work that way?
> Is it
> This could be cleaned up rather dramatically if we were to use one of
> the file locking primitives supplied by the OS to grab an exclusive
> lock on the file, ...
> ...
> The first question for the group is: is it worth doing that?
In the past it has been proposed and declined -- there is some
Kevin Brown <[EMAIL PROTECTED]> writes:
> This could be cleaned up rather dramatically if we were to use one of
> the file locking primitives supplied by the OS to grab an exclusive
> lock on the file, and the upside is that, when the locking code is
> used, the postmaster would *know* whether or n
> file descriptor (closing the file means losing the lock), and we'd
> still have to retain the old code anyway in the event that there is no
> suitable file locking mechanism to use on the platform in question.
What is the gain given the above statement? If what we currently do can
cause issues
Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Brown
> Sent: Friday, 31 January 2003 11:24 AM
> To: PostgreSQL Development
> Subject: [HACKERS] On file locking
>
>
> I've been looking at the PID file creation mechanism we currentl
I've been looking at the PID file creation mechanism we currently use.
It goes through a loop in an attempt to create the PID file, and if
one is there it attempts to remove it if the PID it contains no longer
exists (there are checks for shared memory usage as well).
This could be cleaned up rath
21 matches
Mail list logo
