On Jul 9 2025, at 12:35 pm, Andres Freund wrote:
> FWIW, I've started to wonder if we shouldn't just get rid of the freelist
> entirely. While clocksweep is perhaps minutely slower in a single
> thread than
> the freelist, clock sweep scales *considerably* better [1]. As it's rather
> rare to
Hello,
In conversations [1] recently about considering how best to adapt the code to
become NUMA-aware Andres commented, "FWIW, I've started to wonder if we
shouldn't just get rid of the freelist entirely" and because I'm a glutton for
punishment (and I think this idea has some merit) I took hi
On Fri, Jul 11, 2025, at 2:50 PM, Nathan Bossart wrote:
> On Fri, Jul 11, 2025 at 01:26:53PM -0400, Greg Burd wrote:
>> This change does remove the have_free_buffer() function used by the
>> contrib/pg_prewarm module. On the surface this doesn't seem to cause any
>>
On Fri, Jul 11, 2025, at 2:52 PM, Andres Freund wrote:
Hi,
On 2025-07-11 13:26:53 -0400, Greg Burd wrote:
In conversations [1] recently about considering how best to adapt the
code
to become NUMA-aware Andres commented, "FWIW, I've started to wonder
if we
shouldn't just
in autoprewarm, it's a rather trivial
> patch. And I really couldn't measure regressions above the noise level, even
> if absurdly extreme use cases.
Hmmm... was "argue for keeping the clock sweep" supposed to read "argue
for keeping the freelist"?
> On 2025-0
On 7/21/25 14:35, Andres Freund wrote:
> Hi,
>
> On 2025-07-21 13:37:04 -0400, Greg Burd wrote:
>> On 7/18/25 13:03, Andres Freund wrote:
>> Hello. Thanks again for taking the time to review the email and patch,
>> I think we're onto something good here.
>>
On 7/25/25 15:02, Greg Burd wrote:
> Patch set is now:
>
> 1) remove freelist
>
> 2) remove buffer_strategy_lock
>
> 3) abstract clock-sweep to type and API
>
>
>
> -greg
Somehow including the test.c file as an attachment on my last email
confused the CI and
On 7/22/25 14:43, Greg Burd wrote:
> On 7/21/25 14:35, Andres Freund wrote:
>> Hi,
>>
>> On 2025-07-21 13:37:04 -0400, Greg Burd wrote:
>>> On 7/18/25 13:03, Andres Freund wrote:
>>> Hello. Thanks again for taking the time to review the email and patch,
>
> On Jul 30, 2025, at 8:09 AM, Daniel Gustafsson wrote:
>
>> On 30 Jul 2025, at 11:58, Laurenz Albe wrote:
>>
>> On Tue, 2025-07-29 at 20:24 +0200, Tomas Vondra wrote:
>>> So, what should we do with the PG18 open item? We (the RMT team) would
>>> like to know if we shall keep the checksums e
> On Jul 31, 2025, at 10:06 AM, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> I had this lying around as a draft patch, as part of my ongoing campaign
>> to convert many complicated macros to static inline functions. Since
>> the topic was mentioned in another thread [0], I cleaned up the
etermined inside those function, otherwise every caller would have to
> repeat that. I think this is unnecessary/inconvenient.
Okay, I understand that. At one point I had implementations for
ClockPro and SIEVE but you're right.
> regards
>
>
> [1]
> https://www.post
Hello,
I've been working on Bitmapset and while creating a test suite for it I
found that there is a missing bounds check in bms_prev_member(). The
function takes the prevbit argument and converts it to an index into the
words array using WORDNUM() without checking to ensure that prevbit is
within
On Aug 14 2025, at 9:46 am, David Rowley wrote:
> On Fri, 15 Aug 2025 at 01:21, Greg Burd wrote:
>> I've been working on Bitmapset and while creating a test suite for it I
>> found that there is a missing bounds check in bms_prev_member(). The
>> function take
On Aug 14 2025, at 10:06 am, Tom Lane wrote:
> David Rowley writes:
>> There's a comment saying:
>> * "prevbit" must NOT be more than one above the highest possible bit
>> that can
>> * be set at the Bitmapset at its current size.
>> So looks like it's the fault of the calling code and not a
On Aug 14 2025, at 11:14 am, Tom Lane wrote:
> David Rowley writes:
>> It is valid to pass prevbit as a->nwords * BITS_PER_BITMAPWORD as the
>> code does "prevbit--;". Maybe it would be less confusing if it were
>> written as:
>> * "prevbit" must be less than or equal to "a->nwords * BITS_PER_
On Aug 14 2025, at 11:37 am, Greg Burd wrote:
>
> On Aug 14 2025, at 11:14 am, Tom Lane wrote:
>
>> David Rowley writes:
>>> It is valid to pass prevbit as a->nwords * BITS_PER_BITMAPWORD as the
>>> code does "prevbit--;". Maybe it wou
On Aug 14 2025, at 11:49 am, David Rowley wrote:
> On Fri, 15 Aug 2025 at 03:43, Greg Burd wrote:
>> Well, that was rushed. Apologies.
>
> Would you be ok with adding the Assert after the "a == NULL" check?, i.e:
>
> if (a == NULL || prevbit == 0)
>r
Tom, David,
I really appreciate the time spent and the thoughtful replies on this
thread today. Honestly, I thought this would be a nice and easy single
line fix ahead of a proposal for the addition of tests for Bitmapset[1]
(which identified the issue)
I think, with v5, we're fixing this small i
> On Aug 14, 2025, at 3:45 PM, Tom Lane wrote:
>
> Greg Burd writes:
>> Spoiler alert, I have larger plans[2] for Bitmapset which is why I
>> started down this road to begin with as I wanted to capture the existing
>> API/contract for it before I proposed chang
Hello,
I noticed that there are no tests for Bitmapset in src/test/modules as
is the case for other similar things like radixtree, rbtree, etc. so I
created one. I realize that Bitmapset is already "tested" by all the
other code that uses it, but I was able to find one minor oversight[1]
in that
> On Aug 15, 2025, at 10:25 PM, Thomas Munro wrote:
>
> On Sat, Aug 16, 2025 at 5:58 AM Burd, Greg wrote:
>>> 1. They use CAS in sem_post() because they want to report EOVERFLOW if
>>> you exceed SEM_VALUE_MAX, but POSIX doesn't seem to require that, so I
>>> just used fetch-and-add. Is that
On Aug 17 2025, at 12:57 am, Thomas Munro wrote:
> On Sun, Aug 17, 2025 at 4:34 PM Thomas Munro wrote:
>> Or if you don't like those odds, maybe it'd be OK to keep % but use it
>> rarely and without the CAS that can fail.
>
> ... or if we wanted to try harder to avoid %, could we relegate it
On Thu, Sep 4, 2025, at 12:59 PM, Andres Freund wrote:
> Hi,
>
> On 2025-08-27 15:42:48 -0400, Greg Burd wrote:
>> Regardless, I feel the first two patches on this set address the
>> intention of this thread.
>
> I'm planning to commit the first two patches after
On Fri, Sep 5, 2025, at 12:27 PM, Andres Freund wrote:
> Hi,
>
> On 2025-09-04 13:24:00 -0400, Greg Burd wrote:
>> On Thu, Sep 4, 2025, at 12:59 PM, Andres Freund wrote:
>> > Hi,
>> >
>> > On 2025-08-27 15:42:48 -0400, Greg Burd wrote:
>> >>
24 matches
Mail list logo
