Message-ID: <30fbb76b-4b6f-405e-bf9c-741fe2c7722a@gmail.com>
Date: Thu, 17 Oct 2024 15:12:45 +0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Reference to - BUG #18349: ERROR: invalid DSA memory alloc
 request size 1811939328, CONTEXT: parallel worker
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Craig Milhiser <craig@milhiser.com>,
 pgsql-bugs@lists.postgresql.org
References: 
 <CA+wnhO1OfgXbmXgC4fv_uu=OxcDQuHvfoQ4k0DFeB0Qqd-X-rQ@mail.gmail.com>
 <CA+wnhO2NDZFWB1TrZga-uLzpfSDjKH5Axa2d2+1Q76JSsS7yMg@mail.gmail.com>
 <CA+wnhO0S2kxJ2_M57uJXRocMpcDtz6N4RkP-3Xy=pFs1wp7hmg@mail.gmail.com>
 <CA+hUKGLPKWamfKjtEkPLvRDSeOqoZZ0wDfU65d-hF-1upL8iGw@mail.gmail.com>
 <CA+wnhO3kT7mxbadbteppSZVcs3FRPvGL5xTY2DbrWSGohmhyVw@mail.gmail.com>
 <6785e9e8-4c64-41b0-9e72-c13d1822b599@gmail.com>
 <CA+wnhO0VdTP9OVdZP9bmkavma2WkE-pYpP1yW8yDwRrJ97j-2g@mail.gmail.com>
 <0c3b0e1b-55d1-42b6-8c3c-4392479187db@gmail.com>
 <CA+wnhO2sHcUOfi6_gvaoPMk=2DsKUOWkDjdUtGxJOguQOXDvOQ@mail.gmail.com>
 <cc488d1c-6477-4e20-8bd0-cf152a2e59bf@gmail.com>
 <CA+wnhO3t7xqCiDmGduxgg1Mv5M5R-GeQd0kzVcJKkUFkj91Wbw@mail.gmail.com>
 <CA+hUKGLYx2GGd8BggND5QnyyJKbf1r+Q0cEYWrN+miXzaxwGNA@mail.gmail.com>
 <3581840.1728887169@sss.pgh.pa.us>
 <3a1ac6f1-ac30-4ed4-8d0d-beb8a5aca7e5@gmail.com>
 <CA+hUKGKOoxiGBqv=RA-e8=LXNhdmRCC_rOYbpaqbL16=4wvJ3A@mail.gmail.com>
Content-Language: en-AU
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CA+hUKGKOoxiGBqv=RA-e8=LXNhdmRCC_rOYbpaqbL16=4wvJ3A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/30fbb76b-4b6f-405e-bf9c-741fe2c7722a%40gmail.com>
Precedence: bulk

On 10/16/24 16:19, Thomas Munro wrote:
> On Mon, Oct 14, 2024 at 10:16 PM Andrei Lepikhov <lepihov@gmail.com> wrote:
>> See the attachment for a sketch of the solution.
> 
> Thanks Andrei, I mostly agree with your analysis, but I came up with a
> slightly different patch.  I think we should check for extreme skew if
> old_batch->space_exhausted (the parent partition).  Your sketch always
> does it for batch 0, which works for these examples but I don't think
> it's strictly correct: if batch 0 didn't run out of memory, it might
> falsely report extreme skew just because it had (say) 0 or 1 tuples.
Yeah, I misunderstood the meaning of the estimated_size variable. Your 
solution is more universal. Also, I confirm, it passes my synthetic  test.
Also, it raises the immediate question: What if we have too many 
duplicates? Sometimes, in user complaints, I see examples where they, 
analysing the database's logical consistency, pass through millions of 
duplicates to find an unexpected value. Do we need a top memory 
consumption limit here? I recall a thread in the mailing list with a 
general approach to limiting backend memory consumption, but it is 
finished with no result.
The patch looks good as well as commentary.

-- 
regards, Andrei Lepikhov