public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dmitry Dolgov <[email protected]>
To: Ilmar Yunusov <[email protected]>
Cc: [email protected]
Subject: Re: File locks for data directory lockfile in the context of Linux namespaces
Date: Tue, 23 Jun 2026 16:29:41 +0200
Message-ID: <xhzl7ll7fwmlecg4htsgvr3fcwcec4cvugqebphofvcz4srkkn@vpwa2zgswuwy> (raw)
In-Reply-To: <54uh7vhavffktp72dmjm7ms26lntxacnvpwuaitiez4izugdi6@emwc2yrpqwk2>
References: <z2u3jtjzhqofqhrjvfgkwl4cczhpqibz3t47gpx7fbe7ceaihk@i5mveu2wfpxn>
	<45swup77t7utfy33lu47mvkb4exzm3oeakz25abqxuvmsyzt3c@5umrpfgc3ypg>
	<178066304625.594057.12185296716401427152.pgcf@coridan.postgresql.org>
	<54uh7vhavffktp72dmjm7ms26lntxacnvpwuaitiez4izugdi6@emwc2yrpqwk2>

> 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.

view thread (9+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: File locks for data directory lockfile in the context of Linux namespaces
  In-Reply-To: <xhzl7ll7fwmlecg4htsgvr3fcwcec4cvugqebphofvcz4srkkn@vpwa2zgswuwy>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox