From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Frits Jalvingh <jal(at)etc(dot)to>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15225: [XX000] ERROR: invalid DSA memory alloc request size 1073741824 / Where: parallel worker |
Date: | 2018-06-08 03:09:38 |
Message-ID: | CAEepm=0yCxHGtdJQr04u9EDSUCM03pDWYSkc987pPyq6zzCzhg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Jun 7, 2018 at 4:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Frits Jalvingh <jal(at)etc(dot)to> writes:
>> The "good" news is that this effect is apparently caused by something else.
>> I fired those statements through an IDE (IntelliJ) written in Java and
>> using jdbc. There seems to be something odd going on in there, because when
>> I paste the query in psql then the effect with and without explain looks
>> the same: 3 processes of which 2 "parallel workers" doing enormous amounts
>> of I/O at 50..90% CPU. I will try to find out what easter egg in either
>> that IDE or the JDBC driver causes this 8-/.
>
> Ah. Something about query parameterization, is my bet.
The symptoms match this other report I just diagnosed over here:
We only allow parallelism if you asked for all rows to be returned,
but these GUI tools ask for a limited number. This is probably an
unintended consequence of commit 691b8d59, but I'm not sure. Let's
discuss that over in that other thread.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-06-08 04:06:27 | Re: BUG #15232: Query execution changes based on using 'explain analyze' or not |
Previous Message | Thomas Munro | 2018-06-08 01:24:07 | Re: BUG #15232: Query execution changes based on using 'explain analyze' or not |