Re: Reference to - BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Milhiser <craig(at)milhiser(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Reference to - BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker
Date: 2024-10-17 08:12:45
Message-ID: 30fbb76b-4b6f-405e-bf9c-741fe2c7722a@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 10/16/24 16:19, Thomas Munro wrote:
> On Mon, Oct 14, 2024 at 10:16 PM Andrei Lepikhov <lepihov(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Langote 2024-10-17 08:15:49 Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
Previous Message PG Bug reporting form 2024-10-17 08:05:17 BUG #18660: information_schema.columns.ordinal_position has gaps when primary key columns are dropped