From: | gzh <gzhcoder(at)126(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: ERROR: stack depth limit exceeded |
Date: | 2023-09-11 04:57:39 |
Message-ID: | 4044d693.36c1.18a829a3990.Coremail.gzhcoder@126.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thank you all for taking the time to help me with my question and offer your advice. Your responses were greatly appreciated!
At 2023-09-08 21:53:33, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>gzh <gzhcoder(at)126(dot)com> writes:
>> In the Release Notes for PostgreSQL 12.14, we saw the following change:
>> https://www.postgresql.org/docs/release/12.14/
>
>>> Add recursion and looping defenses in subquery pullup (Tom Lane)
>>> A contrived query can result in deep recursion and unreasonable amounts of time spent trying to flatten subqueries. A proper fix for that seems unduly invasive for a back-patch, but we can at least add stack depth checks and an interrupt check to allow the query to be cancelled.
>
>
>> Our understanding is that this change will cause some complex SQL statements
>> that were previously not reporting errors to report errors in the new version.
>
>The key word there is "contrived". You are not going to hit this limit
>without intentionally trying. The example that led to adding this check
>was a synthetic query with 10000 UNION ALL branches:
>
>https://www.postgresql.org/message-id/flat/703c09a2-08f3-d2ec-b33d-dbecd62428b8%40postgrespro.ru
>
>Also notice that the query misbehaved before this patch, too, by consuming
>excessive RAM.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eduardo Gargiulo | 2023-09-11 13:55:43 | Can't drop logical replication slot |
Previous Message | David G. Johnston | 2023-09-10 17:50:29 | Re: pgsql --echo-errors --quiet and setval |