public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dmitry Dolgov <[email protected]>
To: Zsolt Parragi <[email protected]>
Cc: [email protected]
Subject: Re: File locks for data directory lockfile in the context of Linux namespaces
Date: Fri, 10 Jul 2026 12:20:13 +0200
Message-ID: <uljhsglx5lo4ox3xxkjoov4ye7l3s6xh66gw4gfysgxpla7vgk@fl6arpructd2> (raw)
In-Reply-To: <CAN4CZFMepY-70PqQjefnFFR1VFjvos5EnkpU75ho9bvQj=KXoQ@mail.gmail.com>
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>

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

view thread (3+ messages)

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: <uljhsglx5lo4ox3xxkjoov4ye7l3s6xh66gw4gfysgxpla7vgk@fl6arpructd2>

* 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