Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-hackers by date

  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?