Date: Mon, 13 Mar 2023 10:35:28 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Yurii Rashkovskii <yrashk@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name
Message-ID: <20230313173528.GA195204@nathanxps13>
References: <CA+RLCQyjFV5Y8tG5QgUb6gjteL4S3p+1gcyqWTqigyM93WZ9Pg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+RLCQyjFV5Y8tG5QgUb6gjteL4S3p+1gcyqWTqigyM93WZ9Pg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20230313173528.GA195204%40nathanxps13>
Precedence: bulk

On Mon, Mar 13, 2023 at 07:57:47AM -0700, Yurii Rashkovskii wrote:
> However, there are use cases where [potentially] longer names are
> expected/desired; for example, test benches (where library files may not
> [or can not] be copied to Postgres installation) or alternative library
> installation methods that do not put them into $libdir.
> 
> The patch is backwards-compatible and ensures that bgw_library_name stays
> *at least* as long as BGW_MAXLEN. Existing external code that uses
> BGW_MAXLEN is a length boundary (for example, in `strncpy`) will continue
> to work as expected.

I see that BGW_MAXLEN was originally set to 64 in 2013 (7f7485a) [0], but
was increased to 96 in 2018 (3a4b891) [1].  It seems generally reasonable
to me to increase the length of bgw_library_name further for the use-case
you describe, but I wonder if it'd be better to simply increase BGW_MAXLEN
again.  However, IIUC bgw_library_name is the only field that is likely to
be used for absolute paths, so only increasing that one to MAXPGPATH makes
sense.

[0] https://postgr.es/m/CA%2BTgmoYtQQ-JqAJPxZg3Mjg7EqugzqQ%2BZBrpnXo95chWMCZsXw%40mail.gmail.com
[1] https://postgr.es/m/304a21ab-a9d6-264a-f688-912869c0d7c6%402ndquadrant.com

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com