> On 13 Mar 2023, at 18:35, Nathan Bossart <nathandboss...@gmail.com> wrote: > > 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.
Yeah, raising just bgw_library_name to MAXPGPATH seems reasonable here. While the memory usage does grow it's still quite modest, and has an upper limit in max_worker_processes. While here, I wonder if we should document what BGW_MAXLEN is defined as in bgworker.sgml? -- Daniel Gustafsson
