Re: On file locking

Поиск
Список
Период
Сортировка
От Kevin Brown
Тема Re: On file locking
Дата
Msg-id 20030201163103.GO12957@filer
обсуждение исходный текст
Ответ на Re: On file locking  (Curt Sampson <cjs@cynic.net>)
Ответы Re: On file locking  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: On file locking  (Antti Haapala <antti.haapala@iki.fi>)
Список pgsql-hackers
Curt Sampson wrote:
> On Fri, 31 Jan 2003, Shridhar Daithankar<shridhar_daithankar@persistent.co.in> 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 certainly not on Xenix, SCO Unix, any of the BSDs, Linux,
> SunOS, Solaris, and Tru64 Unix.
> 
> (I'm talking about the flock system call, here.)

Linux, at least, supports mandatory file locks.  The Linux kernel
documentation mentions that you're supposed to use fcntl() or lockf()
(the latter being a library wrapper around the former) to actually
lock the file but, when those operations are applied to a file that
has the setgid bit set but without the group execute bit set, the
kernel enforces it as a mandatory lock.  That means that operations
like open(), read(), and write() initiated by other processes on the
same file will block (or return EAGAIN, if O_NONBLOCK was used to open
it) if that's what the lock on the file calls for.

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.

So if we wanted to make use of mandatory locks, we'd have to refrain
from using flock().




-- 
Kevin Brown                          kevin@sysexperts.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pg_dump is broken by recent privileges changes
Следующее
От: Tom Lane
Дата:
Сообщение: Re: POSIX regex performance bug in 7.3 Vs. 7.2