Re: Improving backend startup interlock
От | Michael Paesold |
---|---|
Тема | Re: Improving backend startup interlock |
Дата | |
Msg-id | 034501c26bff$a7fccbb0$4201a8c0@beeblebrox обсуждение исходный текст |
Ответ на | Re: Improving backend startup interlock (Giles Lean <giles@nemeton.com.au>) |
Список | pgsql-hackers |
Giles Lean <giles@nemeton.com.au> wrote: > 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 ... Well, I am going to do some tests with postgresql and our netapp filer later in October. If that setup proves to work fast and reliable I would also be interested in such a locking. I don't care about the feature if I find the postgresql/NFS/netapp-filer setup to be unreliable or bad performing. I'll see. Regards, Michael Paesold
В списке pgsql-hackers по дате отправления: