From: | Giles Lean <giles(at)nemeton(dot)com(dot)au> |
---|---|
To: | Curt Sampson <cjs(at)cynic(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: On file locking |
Date: | 2003-02-02 22:08:38 |
Message-ID: | 353.1044223718@nemeton.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Curt Sampson <cjs(at)cynic(dot)net> 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.
>
> Definitely. I wonder about the NetBSD manpage quotes in the post you
> followed up to, given that last time I checked flock() was implmented,
> in the kernel, using fcntl(). Either that's changed, or the manpages
> are unclear or lying.
Using the same kernel code != same semantics.
I think the NetBSD manual pages are trying to say that it's "safe" to
have lockf(), fcntl(), and flock() locking playing together. That
needn't be the case on all operating systems and the standards don't
require it.
> This has been my experience in the past; locking semantics are subtle
> and unclear enough that you really need to test for exactly what you
> want at build time on every system, and you've got to do this testing
> on the filesystem you intend to put the locks on.
What he said ...
Giles
From | Date | Subject | |
---|---|---|---|
Next Message | Terri Lerose | 2003-02-02 23:52:21 | unsubscribe |
Previous Message | Jakub Ouhrabka | 2003-02-02 21:53:04 | Re: Case Studio II |