Re: Improving backend startup interlock

Поиск
Список
Период
Сортировка
От Giles Lean
Тема Re: Improving backend startup interlock
Дата
Msg-id 17431.1033773895@nemeton.com.au
обсуждение исходный текст
Ответ на Re: Improving backend startup interlock  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane writes:

> $ man flock
> No manual entry for flock.
> $
> 
> HPUX has generally taken the position of adopting both BSD and SysV
> features, so if it doesn't exist here, it's not portable to older
> Unixen ...

If only local locking is at issue then finding any one of fcntl()
locking, flock(), or lockf() would do.  All Unixen will have one or
more of these and autoconf machinery exists to find them.

The issue Tom raised about NFS support remains: locking over NFS
introduces new failure modes.  It also only works for NFS clients
that support NFS locking, which not all do.

Mind you NFS users are currently entirely unprotected from someone
starting a postmaster on a different NFS client using the same data
directory right now, which file locking would prevent. So there is
some win for NFS users as well as local filesystem users.  (Anyone
using NFS care to put their hand up?  Maybe nobody does?)

Is the benefit of better local filesystem behaviour plus multiple
client protection for NFS users who have file locking enough to
outweigh the drawbacks?  My two cents says it is, but my two cents are
worth approximately USD$0.01, which is to say not very much ...

Regards,

Giles


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

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: Potential Large Performance Gain in WAL synching
Следующее
От: "Curtis Faith"
Дата:
Сообщение: fsync exlusive lock evidence WAS: Potential Large Performance Gain in WAL synching