| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Yurii Rashkovskii <yrashk(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name |
| Date: | 2023-04-21 20:44:51 |
| Message-ID: | 20230421204451.GC1440148@nathanxps13 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 21, 2023 at 10:49:48AM +0200, Daniel Gustafsson wrote:
> On 21 Apr 2023, at 01:32, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>> I am -0.5 for this. If you are writing a new background worker, it's
>> probably reasonable to expect that you can locate the definition of
>> BGW_MAXLEN.
>
> Of course. The question is if it's a helpful addition for someone who is
> reading the documentation section on implementing background workers where we
> explicitly mention BGW_MAXLEN without saying what it is.
IMHO it's better to have folks use the macro so that their calls to
snprintf(), etc. are updated when BGW_MAXLEN is changed. But I can't say
I'm strongly opposed to adding the value to the docs if you think it is
helpful.
>> Also, I think there's a good chance that we'd forget to update
>> such documentation the next time we adjust it.
>
> There is that, but once set to MAXPGPATH it seems unlikely to change
> particularly often so it seems the wrong thing to optimize for.
True.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2023-04-21 20:45:50 | Re: Order changes in PG16 since ICU introduction |
| Previous Message | Melanie Plageman | 2023-04-21 20:44:48 | Re: Memory leak from ExecutorState context? |