From: Tom Lane <tgl@sss.pgh.pa.us>
To: gzh <gzhcoder@126.com>
cc: pgsql-general@lists.postgresql.org
Subject: Re: ERROR: stack depth limit exceeded
In-reply-to: <1211c4ba.2822.18a72d975fc.Coremail.gzhcoder@126.com>
References: <1e6b9056.492e.18a6e9a1798.Coremail.gzhcoder@126.com>
 <1694898.1694093396@sss.pgh.pa.us>
 <1211c4ba.2822.18a72d975fc.Coremail.gzhcoder@126.com>
Comments: In-reply-to gzh <gzhcoder@126.com>
	message dated "Fri, 08 Sep 2023 11:32:48 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1871318.1694181213.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 08 Sep 2023 09:53:33 -0400
Message-ID: <1871319.1694181213@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1871319.1694181213%40sss.pgh.pa.us>
Precedence: bulk

gzh  <gzhcoder@126.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 u=
nduly invasive for a back-patch, but we can at least add stack depth check=
s and an interrupt check to allow the query to be cancelled.


> Our understanding is that this change will cause some complex SQL statem=
ents =

> that were previously not reporting errors to report errors in the new ve=
rsion. =


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-dbecd62=
428b8%40postgrespro.ru

Also notice that the query misbehaved before this patch, too, by consuming
excessive RAM.

			regards, tom lane