[PATCH] Extend the length of BackgroundWorker.bgw_library_name - Mailing list pgsql-hackers

From Yurii Rashkovskii
Subject [PATCH] Extend the length of BackgroundWorker.bgw_library_name
Date
Msg-id CA+RLCQyjFV5Y8tG5QgUb6gjteL4S3p+1gcyqWTqigyM93WZ9Pg@mail.gmail.com
Whole thread Raw
Responses Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name  (Nathan Bossart <nathandbossart@gmail.com>)
Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Hi,

I want to suggest a patch against master (it may also be worth backporting it) that makes it possible to use longer filenames (such as those with absolute paths) in `BackgroundWorker.bgw_library_name`.

`BackgroundWorker.bgw_library_name` currently allows names up to BGW_MAXLEN-1, which is generally sufficient if `$libdir` expansion is used. 

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.

The trade-off of this patch is that the `BackgroundWorker` structure becomes larger. From my perspective, this is a reasonable cost (less than a kilobyte of extra space per worker).

The patch builds and `make check` succeeds.

Any feedback is welcome!

--
Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: Gilles Darold
Date:
Subject: Re: [Proposal] Allow pg_dump to include all child tables with the root table