Hi,
On 2025-02-24 10:50:21 -0500, Andres Freund wrote:
> Since I've not heard anything on that point, I'm currently thinking with going
> with return-by-value. Attached are two very mildly updated patches. Most of
> the changes is added commit messages.
And pushed.
Greetings,
Andres Freund
Hi,
On 2025-02-20 15:28:39 -0500, Andres Freund wrote:
> On 2025-02-20 14:11:16 -0500, Tom Lane wrote:
> > As a matter of style, I wonder if it'd be better to have these
> > functions write into a caller-supplied variable.
>
> I wondered about that too, it does however make some code more awkward
On Sat, Feb 22, 2025 at 1:30 PM Thomas Munro wrote:
> procnumber.h seems like the right place, at least without a separate
> discussion of the ramifications of making it configurable, no? (I
> thought there were ideas about squeezing it down to 16 bits so you
> could jam two of 'em into an atomic
On Sat, Feb 22, 2025 at 5:15 AM Andres Freund wrote:
> On 2025-02-21 18:20:39 +1300, Thomas Munro wrote:
> > On Fri, Feb 21, 2025 at 9:28 AM Andres Freund wrote:
> > Do we even check the binary digits? BTW I see a place in lwlock.c
> > that still talks about 2^23-1, looks like it is out of date.
Hi,
On 2025-02-21 18:20:39 +1300, Thomas Munro wrote:
> On Fri, Feb 21, 2025 at 9:28 AM Andres Freund wrote:
> > The patch curently uses a hardcoded 6 for the length of MAX_BACKENDS. Does
> > anybody have a good idea for how to either
> >
> > a) derive 6 from MAX_BACKENDS in a way that can be use
On Fri, Feb 21, 2025 at 6:20 PM Thomas Munro wrote:
> #define PROCNUMBER_BITS 18
> #define MAX_BACKENDS ((1 << PROCNUMBER_BITS) - 1)
> #define PROCNUMBER_CHARS DECIMAL_DIGITS_FOR_BITS(PROCNUMBER_BITS)
>
> ... with a little helper ported to preprocessor hell from Hacker's
> Delight magic[1] for tha
Thomas Munro writes:
> On Fri, Feb 21, 2025 at 9:28 AM Andres Freund wrote:
>> The patch curently uses a hardcoded 6 for the length of MAX_BACKENDS. Does
>> anybody have a good idea for how to either
>>
>> a) derive 6 from MAX_BACKENDS in a way that can be used in a C array size
This all seems
On Fri, Feb 21, 2025 at 9:28 AM Andres Freund wrote:
> The patch curently uses a hardcoded 6 for the length of MAX_BACKENDS. Does
> anybody have a good idea for how to either
>
> a) derive 6 from MAX_BACKENDS in a way that can be used in a C array size
Do we even check the binary digits? BTW I s
Hi,
On 2025-02-20 14:11:16 -0500, Tom Lane wrote:
> As a matter of style, I wonder if it'd be better to have these
> functions write into a caller-supplied variable.
I wondered about that too, it does however make some code more awkward,
e.g. because there's not a good surrounding block to put th
Andres Freund writes:
> Does anybody have opinions about whether we should keep a backward compatible
> interface in place or not?
I vote for "not" --- doesn't seem like there'll be much external
code affected, and we make comparably-sized API breaks all the time.
As a matter of style, I wonder
On Thu, Feb 20, 2025 at 12:40:57PM -0500, Andres Freund wrote:
> On 2025-02-20 14:00:10 +1300, Thomas Munro wrote:
> > On Wed, Feb 19, 2025 at 3:35 PM Andres Freund wrote:
> > > After thinking about this for an embarassingly long time, I think there's
> > > actually a considerably better answer fo
Hi,
On 2025-02-20 14:00:10 +1300, Thomas Munro wrote:
> On Wed, Feb 19, 2025 at 3:35 PM Andres Freund wrote:
> > After thinking about this for an embarassingly long time, I think there's
> > actually a considerably better answer for a case like this: A function that
> > returns a fixed-length str
On Wed, Feb 19, 2025 at 3:35 PM Andres Freund wrote:
> After thinking about this for an embarassingly long time, I think there's
> actually a considerably better answer for a case like this: A function that
> returns a fixed-length string by value:
>
> - Compilers can fairly easily warn about on-s
Hi,
On 2024-10-06 11:53:59 +0800, Andy Fan wrote:
> Thomas Munro writes:
>
> > On Thu, Sep 5, 2024 at 3:58 AM Andres Freund wrote:
> >> Obviously we could add a version of GetRelationPath() that just prints
> >> into a
> >> caller provided buffer - but that's somewhat awkward API wise.
> >
> >
Thomas Munro writes:
> On Thu, Sep 5, 2024 at 3:58 AM Andres Freund wrote:
>> Obviously we could add a version of GetRelationPath() that just prints into a
>> caller provided buffer - but that's somewhat awkward API wise.
>
> For the record, that's exactly what I did in the patch I proposed to
>
On Thu, Sep 5, 2024 at 3:58 AM Andres Freund wrote:
> Obviously we could add a version of GetRelationPath() that just prints into a
> caller provided buffer - but that's somewhat awkward API wise.
For the record, that's exactly what I did in the patch I proposed to
fix our long standing RelationT
On Wed, Sep 04, 2024 at 11:58:33AM -0400, Andres Freund wrote:
> In general emitting a LOG inside a critical section isn't a huge issue - we
> made sure that elog.c has a reserve of memory to be able to log without
> crashing.
>
> However, the current message for buffer IO issues use relpath*() (e
17 matches
Mail list logo
