BUG #16979: WITH RECURSIVE SQL crashes v13.x - Mailing list pgsql-bugs

The following bug has been logged on the website:

Bug reference:      16979
Logged by:          Robins Tharakan
Email address:      tharakan@gmail.com
PostgreSQL version: 13.2
Operating system:   Ubuntu
Description:

Hi,

This SQL is a stripped down version (from a SQLSmith crash) and am posting
here since this appears to be a regression in v13.

Per documentation, it is probably unwise to increase max_stack_depth just
like that, but I am unclear why this SQL should reach anywhere close to a
stack depth of 32k.

This is reproducible on v13.2 (REL_13_2) but works fine on HEAD (master).
The SQL also worked fine on v12 and older instances (although I didn't
compile them from source for this bug report).

Irrespective, do let me know if I can provide any further details to help
here. Also (may be unrelated, but) it may help that BUG #16978 came up when
reviewing this issue.

=======================================

→ psql -h localhost
psql (14devel, server 13.2)
Type "help" for help.

postgres=# WITH RECURSIVE w1(c1) AS
 (WITH w2(c2) AS
  (WITH w3(c3) AS
   (WITH w4(c4) AS
(WITH w5(c5) AS
 (WITH RECURSIVE w6(c6) AS
  (WITH w6(c6) AS
   (WITH w8(c8) AS
   (WITH w9(c9) AS
   (WITH w10(c10) AS
   (WITH w11(c11) AS
   (WITH w12(c12) AS
   (WITH w13(c13) AS
   (WITH w14(c14) AS
   (WITH w15(c15) AS
(SELECT 1)
SELECT * FROM w15)
SELECT * FROM w14)
SELECT * FROM w13)
SELECT * FROM w12)
SELECT * FROM w11)
SELECT * FROM w10)
SELECT * FROM w9)
SELECT * FROM w8)
   SELECT * FROM w6)
  SELECT * FROM w6)
 SELECT * FROM w5)
SELECT * FROM w4)
   SELECT * FROM w3)
  SELECT * FROM w2)
SELECT * FROM w1;
ERROR:  stack depth limit exceeded
HINT:  Increase the configuration parameter "max_stack_depth" (currently
2048kB), after ensuring the platform's stack depth limit is adequate.

postgres=# show max_stack_depth ;
 max_stack_depth
-----------------
 2MB
(1 row)

postgres=# set max_stack_depth = '7MB';
SET

postgres=# WITH RECURSIVE w1(c1) AS
 (WITH w2(c2) AS
  (WITH w3(c3) AS
   (WITH w4(c4) AS
(WITH w5(c5) AS
 (WITH RECURSIVE w6(c6) AS
  (WITH w6(c6) AS
   (WITH w8(c8) AS
   (WITH w9(c9) AS
   (WITH w10(c10) AS
   (WITH w11(c11) AS
   (WITH w12(c12) AS
   (WITH w13(c13) AS
   (WITH w14(c14) AS
   (WITH w15(c15) AS
(SELECT 1)
SELECT * FROM w15)
SELECT * FROM w14)
SELECT * FROM w13)
SELECT * FROM w12)
SELECT * FROM w11)
SELECT * FROM w10)
SELECT * FROM w9)
SELECT * FROM w8)
   SELECT * FROM w6)
  SELECT * FROM w6)
 SELECT * FROM w5)
SELECT * FROM w4)
   SELECT * FROM w3)
  SELECT * FROM w2)
SELECT * FROM w1;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!?> \q



→ wc -l gdb_20210423_1022.txt
32807 gdb_20210423_1022.txt

→ head gdb_20210423_1022.txt
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000000000057b832 in makeDependencyGraphWalker ()
#0  0x000000000057b832 in makeDependencyGraphWalker ()
#1  0x000000000057b832 in makeDependencyGraphWalker ()
#2  0x000000000057b832 in makeDependencyGraphWalker ()
#3  0x000000000057b832 in makeDependencyGraphWalker ()
#4  0x000000000057b832 in makeDependencyGraphWalker ()
#5  0x000000000057b832 in makeDependencyGraphWalker ()

→ tail -40 gdb_20210423_1022.txt
#32763 0x000000000057b727 in makeDependencyGraphWalker ()
#32764 0x000000000057b727 in makeDependencyGraphWalker ()
#32765 0x000000000057b727 in makeDependencyGraphWalker ()
#32766 0x000000000057b727 in makeDependencyGraphWalker ()
#32767 0x000000000057b727 in makeDependencyGraphWalker ()
#32768 0x000000000057c5a9 in transformWithClause ()
#32769 0x00000000005577bb in transformStmt ()
#32770 0x0000000000558b3c in parse_sub_analyze ()
#32771 0x000000000057bfd0 in analyzeCTE ()
#32772 0x000000000057c917 in transformWithClause ()
#32773 0x00000000005577bb in transformStmt ()
#32774 0x0000000000558b3c in parse_sub_analyze ()
#32775 0x000000000057bfd0 in analyzeCTE ()
#32776 0x000000000057c917 in transformWithClause ()
#32777 0x00000000005577bb in transformStmt ()
#32778 0x0000000000558b3c in parse_sub_analyze ()
#32779 0x000000000057bfd0 in analyzeCTE ()
#32780 0x000000000057c917 in transformWithClause ()
#32781 0x00000000005577bb in transformStmt ()
#32782 0x0000000000558b3c in parse_sub_analyze ()
#32783 0x000000000057bfd0 in analyzeCTE ()
#32784 0x000000000057c917 in transformWithClause ()
#32785 0x00000000005577bb in transformStmt ()
#32786 0x0000000000558b3c in parse_sub_analyze ()
#32787 0x000000000057bfd0 in analyzeCTE ()
#32788 0x000000000057c8a0 in transformWithClause ()
#32789 0x00000000005577bb in transformStmt ()
#32790 0x000000000055948f in parse_analyze ()
#32791 0x0000000000769102 in pg_analyze_and_rewrite ()
#32792 0x0000000000769673 in exec_simple_query ()
#32793 0x000000000076b7e5 in PostgresMain ()
#32794 0x00000000006f60cf in ServerLoop ()
#32795 0x00000000006f6fcf in PostmasterMain ()
#32796 0x0000000000486289 in main ()


-
Robins Tharakan
Database Engineer
Amazon Web Services