Re: Unresolved error 0xC0000409 on Windows Server - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Unresolved error 0xC0000409 on Windows Server
Date
Msg-id 24361.1352654544@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unresolved error 0xC0000409 on Windows Server  (Matthew Gerber <gerber.matthew@gmail.com>)
Responses Re: Unresolved error 0xC0000409 on Windows Server  (Matthew Gerber <gerber.matthew@gmail.com>)
Re: Unresolved error 0xC0000409 on Windows Server  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Matthew Gerber <gerber.matthew@gmail.com> writes:
> On Sun, Nov 11, 2012 at 11:19 AM, Tom Lane <tgl@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
depthlimit 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?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Matthew Gerber
Date:
Subject: Re: Unresolved error 0xC0000409 on Windows Server
Next
From: Tomas Vondra
Date:
Subject: Re: too much pgbench init output