On Sun, Dec 8, 2024 at 7:48 PM Tomas Vondra wrote:
[..]
> >> I have previously encountered situations where the non-garbage-collected
> >> memory of wal_sender was approximately hundreds of megabytes or even
> >> exceeded 1GB, but I was unable to reproduce this situation using simple
> >> SQL. The
On 12/8/24 05:23, Tomas Vondra wrote:
> On 9/18/24 04:56, shawn wang wrote:
>> Thank you very much for your response and suggestions.
>>
>> As you mentioned, the patch here is actually designed for glibc's
>> ptmalloc2 andis not applicable to other platforms. I will consider
>> supporting it onl
On 9/18/24 04:56, shawn wang wrote:
> Thank you very much for your response and suggestions.
>
> As you mentioned, the patch here is actually designed for glibc's
> ptmalloc2 andis not applicable to other platforms. I will consider
> supporting it only on the Linux platform in the future. In the m
Thank you very much for your response and suggestions.
As you mentioned, the patch here is actually designed for glibc's ptmalloc2
andis not applicable to other platforms. I will consider supporting it only
on the Linux platform in the future. In the memory management strategy of
ptmalloc2, there
I wrote:
> The single test case you showed suggested that maybe we could
> usefully prod glibc to free memory at query completion, but we
> don't need all this interrupt infrastructure to do that. I think
> we could likely get 95% of the benefit with about a five-line
> patch.
To try to quantify
shawn wang writes:
> I have successfully registered my patch for the commitfest. However, upon
> integration, I encountered several errors during the testing phase. I am
> currently investigating the root causes of these issues and will work on
> providing the necessary fixes.
I should think the
Thank you for your valuable suggestion.
I have successfully registered my patch for the commitfest. However, upon
integration, I encountered several errors during the testing phase. I am
currently investigating the root causes of these issues and will work on
providing the necessary fixes. If you
On Thu, 12 Sept 2024 at 14:40, shawn wang wrote:
> Could you please perform another round of testing to ensure that everything
> is functioning as expected with this modification?
One way to get a few machines with various build systems testing this
is to register the patch on the commitfest app
Hi Rafia,
I have made the necessary adjustment by replacing the inclusion of malloc.h
with stdlib.h in the relevant codebase. This change should address the
previous concerns regarding memory allocation functions.
Could you please perform another round of testing to ensure that everything
is func
Unfortunately, I still see a compiling issue with this patch,
memtrim.c:15:10: fatal error: 'malloc.h' file not found
#include
^~
1 error generated.
On Wed, 28 Aug 2024 at 12:54, shawn wang wrote:
> Hi Ashutosh,
>
> Ashutosh Bapat 于2024年8月26日周一 19:05写道：
>
>> Hi Shawn,
>> It w
Hi Ashutosh,
Ashutosh Bapat 于2024年8月26日周一 19:05写道：
> Hi Shawn,
> It will be good to document usage of this function. Please add
> document changes in your patch. We need to document the impact of this
> function so that users can judiciously decide whether or not to use
> this function and under
Hi Shawn,
It will be good to document usage of this function. Please add
document changes in your patch. We need to document the impact of this
function so that users can judiciously decide whether or not to use
this function and under what conditions. Also they would know what to
expect when they
Hi Ashutosh, thank you for your response.
Firstly, the purpose of caching memory in malloc is for performance, so
when we execute malloc_trim(), it will affect the efficiency of memory
usage in the subsequent operation. Secondly, the function of malloc_trim()
is to lock and traverse the bins, then
Thank you Rafia. Here is a v2 patch.
Rafia Sabih 于2024年8月23日周五 18:30写道：
>
>
> On Fri, 23 Aug 2024 at 10:54, shawn wang wrote:
>
>> Hi hackers,
>>
>> Currently, all processes in PostgreSQL actually use malloc to allocate
>> and free memory. In the case of long connections where business queries
Hi Shawn,
On Fri, Aug 23, 2024 at 2:24 PM shawn wang wrote:
>
> Hi hackers,
>
> Currently, all processes in PostgreSQL actually use malloc to allocate and
> free memory. In the case of long connections where business queries are
> executed over extended periods, the distribution of memory can
On Fri, 23 Aug 2024 at 10:54, shawn wang wrote:
> Hi hackers,
>
> Currently, all processes in PostgreSQL actually use malloc to allocate
> and free memory. In the case of long connections where business queries are
> executed over extended periods, the distribution of memory can become
> extremel
16 matches
Mail list logo
