Date: Fri, 10 Jul 2026 12:20:13 +0200
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: File locks for data directory lockfile in the context of Linux
 namespaces
Message-ID: <uljhsglx5lo4ox3xxkjoov4ye7l3s6xh66gw4gfysgxpla7vgk@fl6arpructd2>
References: <z2u3jtjzhqofqhrjvfgkwl4cczhpqibz3t47gpx7fbe7ceaihk@i5mveu2wfpxn>
 <45swup77t7utfy33lu47mvkb4exzm3oeakz25abqxuvmsyzt3c@5umrpfgc3ypg>
 <178066304625.594057.12185296716401427152.pgcf@coridan.postgresql.org>
 <54uh7vhavffktp72dmjm7ms26lntxacnvpwuaitiez4izugdi6@emwc2yrpqwk2>
 <xhzl7ll7fwmlecg4htsgvr3fcwcec4cvugqebphofvcz4srkkn@vpwa2zgswuwy>
 <178332300475.2568959.4097339122938147476.pgcf@coridan.postgresql.org>
 <c5jj2zvhnh36xfvqkcogrvk5fkcut3un5q5hibozfm62h6t4kp@sdlorh7uaf2s>
 <CAN4CZFMepY-70PqQjefnFFR1VFjvos5EnkpU75ho9bvQj=KXoQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAN4CZFMepY-70PqQjefnFFR1VFjvos5EnkpU75ho9bvQj=KXoQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/uljhsglx5lo4ox3xxkjoov4ye7l3s6xh66gw4gfysgxpla7vgk%40fl6arpructd2>
Precedence: bulk

> On Mon, Jul 06, 2026 at 03:07:35PM -0700, Zsolt Parragi wrote:
> +		if (errno == EAGAIN)
> +			ereport(FATAL,
> +					(errcode(ERRCODE_LOCK_FILE_EXISTS),
> 
> According to fcntl.2, this should handle both EACCESS and EAGAIN:
> 
> ERRORS
>        EACCES or EAGAIN
>               Operation is prohibited by locks held by other processes.

Good point. From what I see after a cursory look at fcntl is that it
normally returns EAGAIN, but filesystems are allowed to implement a
custom lock operation, so it makes sense to be prepared.

> +static int
> +OFDLockFile(int fd, const char *filename)
> +...
> +	else
> +		return dup(fd);
> 
> Isn't this missing an FD_CLOEXEC, so that launched processes doesn't
> inherit it and keep the lock open possibly longer than needed?

This is an interesting question. I haven't thought about this
originally, but now I think the current approach (no FD_CLOEXEC) is what
is actually needed. We want to keep the lock as long as any existing
process may access the data directory, thus the lock lifetime must be
equal to the lifetime of a longest living process. Currently the lock
file is created by the bootstrap process and the postmaster, which I
think fits the picture.

> Also, shouldn't the code verify the result of dup? (!= -1 / errno)