On Sun, Nov 11, 2012 at 12:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Matthew Gerber <gerber.matt...@gmail.com> writes: > > On Sun, Nov 11, 2012 at 11:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> How long is "long"? > > > I was seeing queries with around 5000-7000 "UNION ALL" statements. > > Hm. I experimented with test queries created like so: > > perl -e 'print "SELECT 1 a, 2 b, 3 c\n"; print "UNION ALL SELECT 1 a, 2 b, > 3 c\n" foreach (1..8200);' | psql > > On the machine I tried this on, it works up to about 8200 and then fails > in the way I'd expect: > > 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. > > But then when I cranked it up to 80000, kaboom: > > connection to server was lost > > Inspection of the core dump shows transformSetOperationTree is the > problem --- it's recursing but lacks a check_stack_depth test. > So that's easy to fix, but I wonder why the critical depth limit seems > to be so much less on your machine. I get the expected error up to > about 65000 UNION ALLs --- why is yours crashing at a tenth of that? > Tom, Interesting. I really have no idea why mine seemed to fail so much sooner. I recalled my 5k-7k figure from memory, so I might be off on that, but probably not by an order of magnitude. In any case, it sounds like you know how to fix the problem. Should I file this as a bug report or will you take care of it from here? Best, Matt
