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

From Yurii Rashkovskii
Subject Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name
Date
Msg-id CA+RLCQyvbdkO-pkL5oaxn6ftGYM7OY+U_KvNwaSCRR1ce2yo5A@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Aleksander,

On Mon, Apr 24, 2023 at 1:01 PM Aleksander Alekseev <aleksander@timescale.com> wrote: 
> 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.

There is a mistake in the comment though:

```
+/*
+ * Ensure bgw_function_name's size is backwards-compatible and sensible
+ */
+StaticAssertDecl(MAXPGPATH >= BGW_MAXLEN, "MAXPGPATH must be at least
equal to BGW_MAXLEN");
```

library_name, not function_name. Also I think the comment should be
more detailed, something like "prior to PG17 we used ... but since
PG17 ... which may cause problems if ...".

This is a very good catch and a suggestion. I've slightly reworked the patch, and I also made this static assertion to have less indirection and, therefore, make it easier to understand the premise. 
Version 2 is attached. 

--
Y.

Attachment

pgsql-hackers by date:

Previous
From: Ajit Awekar
Date:
Subject: Re: Memory leak in CachememoryContext
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [PoC] pg_upgrade: allow to upgrade publisher node