pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Craig Milhiser <craig@milhiser.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Reference to - BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker
Date: Mon, 14 Oct 2024 02:26:09 -0400
Message-ID: <3581840.1728887169@sss.pgh.pa.us> (raw)
In-Reply-To: <96a328e9-4fbf-433b-a8d7-071da18e12c4@gmail.com>
References: <CA+wnhO1OfgXbmXgC4fv_uu=OxcDQuHvfoQ4k0DFeB0Qqd-X-rQ@mail.gmail.com>
	<CA+wnhO1zP13p5sn6d-top=-gmCnE+ymYEfkPbN2d=QKWMbp6Sg@mail.gmail.com>
	<CA+hUKGJo9H75w3QoZrZCVm3eGg7ifJ0UvZZMw6bz=HCpwg0gKw@mail.gmail.com>
	<CA+hUKG+YZpOyP-XXT65o9hx=oGF+9-BJzjqzRXcdvWV=ZrJbTA@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>
	<9! 6a328e9-4fbf-433b-a8d7-071da18e12c4@gmail.com>

Andrei Lepikhov <lepihov@gmail.com> writes:
> My explanation (correct if I'm wrong):
> OUTER JOINs allow NULLs to be in a hash table. At the same time, a hash 
> value for NULL is 0, and it goes to the batch==0.
> If batch number 0 gets overfilled, the 
> ExecParallelHashIncreaseNumBatches routine attempts to increase the 
> number of batches - but nothing happens. The initial batch is still too 
> big, and the number of batches doubles up to the limit.

Interesting point.  If memory serves (I'm too tired to actually look)
the planner considers the statistical most-common-value when
estimating whether an unsplittable hash bucket is likely to be too
big.  It does *not* think about null values ... but it ought to.

However, this does not explain why PHJ would be more subject to
the problem than non-parallel HJ.

			regards, tom lane





view thread (27+ messages)  latest in thread

Message-ID: <3581840.1728887169@sss.pgh.pa.us>
Permalink:  ../3581840.1728887169@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3581840.1728887169@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, lepihov@gmail.com, thomas.munro@gmail.com, craig@milhiser.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: Reference to - BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker
  In-Reply-To: <3581840.1728887169@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox