> On Fri, Jun 19, 2026 at 05:11:11PM +0200, Dmitry Dolgov wrote:
> > Is locking the socket lock file intentional here? If so, maybe the helper name,
> > comment, and fd tracking should reflect that broader scope. If not, perhaps the
> > new lock should be applied only for the isDDLock case; otherwise v2 changes
> > socket lockfile semantics too, not only postmaster.pid.
>
> It's been a while, quite frankly I don't remember. On the face of it, I
> think both the directory and socket lock files should be locked in the
> same way, since both are equally susceptible for the failure scenario
> described in this thread, even if the consequences of a failure are
> different. Let me do some renaming to clarify that.
>
> > While reading that code, I also noticed a small error-path issue: DataDirLockFD
> > starts as 0, but if fcntl(F_OFD_SETLK) fails with a non-EAGAIN error the code
> > only emits a warning and does not assign a duplicate fd. UnlinkLockFiles()
> > then closes DataDirLockFD unconditionally. Initializing it to -1, closing it
> > conditionally, and checking dup(fd) would make that path more explicit.
>
> Good point, I'll address this in the next version.
Something like this should be sufficient I think.