From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Matthew Gerber <gerber(dot)matthew(at)gmail(dot)com>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Unresolved error 0xC0000409 on Windows Server |
Date: | 2012-11-11 19:35:57 |
Message-ID: | 20121111193557.GC5720@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Nov 11, 2012 at 12:22:24PM -0500, Tom Lane wrote:
> 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
I tried this test case on Windows Server 2008 (x64). It hit max_stack_depth
at 9000 UNIONs and crashed at 10000. When I run it under a debugger, the
debugger reports exception 0xC00000FD (STATUS_STACK_OVERFLOW). Run normally,
the server log reports exception 0xC0000005 (STATUS_ACCESS_VIOLATION).
> 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?
So, I can reproduce the lower threshold, but the exception type does not agree
with the one Matthew observed.
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2012-11-11 19:36:46 | Re: PATCH: optimized DROP of multiple tables within a transaction |
Previous Message | Jeff Davis | 2012-11-11 18:27:28 | Re: Enabling Checksums |