From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | jakub(dot)zemanek(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16965: Select query fails with ERROR: XX000: could not find pathkey item to sort |
Date: | 2021-04-15 21:38:50 |
Message-ID: | 20210415213850.GA17131@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Apr 15, 2021 at 04:05:03PM +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 16965
> Logged by: Jakub Zemanek
> Email address: jakub(dot)zemanek(at)gmail(dot)com
> PostgreSQL version: 13.2
> Operating system: Ubuntu 20.04
> Description:
>
> Hi,
> after upgrade of our zabbix database from v 12 to v 13, we have encountered
> error in select queries. When we SET max_parallel_workers_per_gather=0; then
> the query finishes without error. The query looks like this:
> SELECT DISTINCT COUNT(DISTINCT t.triggerid) AS rowscount,i.hostid FROM
> triggers t,functions f,items i WHERE i.hostid=10406 AND
> f.triggerid=t.triggerid AND f.itemid=i.itemid AND t.flags IN (0,4) GROUP BY
> i.hostid;'
> ERROR: XX000: could not find pathkey item to sort
> LOCATION: prepare_sort_from_pathkeys, createplan.c:6013
This issue was reported on April 12 by someone else:
https://www.postgresql.org/message-id/flat/91f3ec99-85a4-fa55-ea74-33f85a5c651f%40swarm64.com
A patch to fix it is being considered. You might want to watch that
thread to test or apply the patch, or wait for a fix in the next minor
release.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-04-16 12:36:35 | Re: BUG #16966: Nested loop joining across tables with varchar -> bpchar cast always scans varchar table first |
Previous Message | PG Bug reporting form | 2021-04-15 21:13:03 | BUG #16966: Nested loop joining across tables with varchar -> bpchar cast always scans varchar table first |