Re: file-locking and postmaster.pid - Mailing list pgsql-hackers

From korry
Subject Re: file-locking and postmaster.pid
Date
Msg-id 1148505837.21335.76.camel@sakai.localdomain
Whole thread Raw
In response to Re: file-locking and postmaster.pid  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: file-locking and postmaster.pid
Re: file-locking and postmaster.pid
List pgsql-hackers
On Wed, 2006-05-24 at 16:34 -0400, Alvaro Herrera wrote: <blockquote type="CITE"><pre>
<font color="#000000">korry wrote:</font>

<font color="#000000">> > The Win32 API for locking seems mighty strange to me.</font>
<font color="#000000">> </font>
<font color="#000000">> Linux/Unix byte locking is advisory (meaning that one lock can block</font>
<font color="#000000">> another lock, but it can't block a read).</font>

<font color="#000000">No -- it is advisory meaning that a process that does not try to acquire</font>
<font color="#000000">the lock is not locked out. </font> 
</pre></blockquote><br /> Right, that's why I said "can block" instead of "will block".  An advisory lock will only
blockanother locker, not another reader (except in Win32).<br /><br /><blockquote type="CITE"><pre>
 
<font color="#000000">You can certainly block a file in exclusive</font>
<font color="#000000">mode, using the LOCK_EX flag.  (And at least on my Linux system, there</font>
<font color="#000000">is mandatory locking too, using the fcntl() interface).</font>
</pre></blockquote><br /> My fault - I'm not really talking about "file locking", I'm talking about byte-range locking
(vialockf() and family). <br /><br /> I don't believe that you can use byte-range locking to block read-access to a
file,you can only use byte-range locking to block other locks.<br /><br /> A simple exclusive lock on the first byte
pastthe end of the file will do.  <br /><br /><blockquote type="CITE"><pre>
 
<font color="#000000">I think the next question is -- how would the lock interface be used?</font>
<font color="#000000">We could acquire an exclusive lock on postmaster start (to make sure no</font>
<font color="#000000">backend is running), then reduce it to a shared lock.  Every backend</font>
<font color="#000000">would inherit the shared lock.  But the lock exchange is not guaranteed</font>
<font color="#000000">to be atomic so a new postmaster could start just after we acquire the</font>
<font color="#000000">lock and acquire the shared lock.  It'd need to be complemented with</font>
<font color="#000000">another lock.</font>
</pre></blockquote><br /> You never need to reduce it to a shared lock.  On postmaster startup, try to lock the
sentinelbyte (one byte past the end-of-file).  If you can lock it, you know that no other postmaster has that byte
locked. If you can't lock it, another postmaster is running. It is an atomic operation. <br /><br /> However, Tom may
becorrect about NFS locking, but I guess I'm surprised that anyone would care :-)<br /><br /><blockquote
type="CITE"><pre>
<font color="#000000">> Win32 locking is mandatory (at least in the most portable form) so a</font>
<font color="#000000">> lock blocks a reader.</font>

<font color="#000000">There is also shared/exclusive locking of a file on Win32. </font> 
</pre></blockquote><br /> Yes, but Win32 shared locking only works on NTFS-type file systems.  And you don't need
sharedlocking anyway.<br /><br />         -- Korry<br /><br /><br /> 

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Compression and on-disk sorting
Next
From: korry
Date:
Subject: Re: file-locking and postmaster.pid