Re: ERROR: stack depth limit exceeded - Mailing list pgsql-general

From gzh
Subject Re: ERROR: stack depth limit exceeded
Date
Msg-id 4044d693.36c1.18a829a3990.Coremail.gzhcoder@126.com
Whole thread Raw
In response to Re: ERROR: stack depth limit exceeded  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@sss.pgh.pa.us> wrote: >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 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

pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: pgsql --echo-errors --quiet and setval
Next
From: Eduardo Gargiulo
Date:
Subject: Can't drop logical replication slot