Re: max_stack_depth problem though query is substantially smaller

I guess you are right. I have narrowed the query down
to a simple create table, followed by an insert, one text field, one hstore field and an integer field.
No temporary table, no BEGIN etc. One record, yet the hstore has 40K kvp. No R involved.
and I still end up with the same error.

Thanks for the pointer to the stack trace backend. I'll try to set that up and report what I find.

________________________________________
From: Tom Lane [tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Friday, April 08, 2016 9:39 PM
To: Bannert Matthias
Cc: Charles Clavadetscher; pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] max_stack_depth problem though query is substantially smaller

"Bannert Matthias" <bannert(at)kof(dot)ethz(dot)ch> writes:
> Thanks for your reply. I do think it is rather a postgres than an R issue, here's why:
> a) R simply puts an SQL string together. What Charles had posted was an excerpt of that string.
> Basically we have 1.7 MB of that string. Everything else is equal just the hstore contains 40K key value pairs.

Well, as a test I ran a query that included an hstore literal with 4
million key/value pairs (a bit shy of 70MB of query text). I didn't see
any misbehavior on a machine with 2MB max_stack_depth. So there's
something else going on in your situation.

I concur with the suggestion to try to get a stack backtrace from the
point of the error. Setting a breakpoint at errfinish() is usually
an effective strategy when you know that the query will provoke a SQL
error report.

https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend

regards, tom lane