On Mon, May 27, 2013 at 5:59 AM, Christopher Browne wrote:
> This situation falls from a problem that we noticed a mighty long time ago
> in Slony, where the set of XIDs outstanding gets very large, and, attendant
> to that, the set of "action id" values by which tuples are being filtered,
> gets
On 6 June 2013 16:13, Gurjeet Singh wrote:
> On Mon, May 27, 2013 at 10:32 AM, Christopher Browne
> wrote:
>>
>> On Mon, May 27, 2013 at 1:42 AM, Gurjeet Singh wrote:
>>>
>>>
Joking about "640K" aside, it doesn't seem reasonable to expect a truly
enormous query as is generated by
On Mon, May 27, 2013 at 10:32 AM, Christopher Browne wrote:
> On Mon, May 27, 2013 at 1:42 AM, Gurjeet Singh wrote:
>
>>
>>
>>> Joking about "640K" aside, it doesn't seem reasonable to expect a truly
>>> enormous query as is generated by the broken forms of this logic to turn
>>> out happily. I'
On Mon, May 27, 2013 at 1:42 AM, Gurjeet Singh wrote:
>
>
>> Joking about "640K" aside, it doesn't seem reasonable to expect a truly
>> enormous query as is generated by the broken forms of this logic to turn
>> out happily. I'd rather fix Slony (as done in the above patch).
>>
>
> Yes, by all m
My last email was written before reading this. A few episodes of 24
occurred between writing and sending that email.
Added slony1-hackers, but didn't remove pgsql-hackers. Feel free to exclude
pgsql lists, as this branch of conversation seems to be more Slony related
than Postgres.
On Sun, May 26
On Sun, May 26, 2013 at 11:46 AM, Tom Lane wrote:
> Josh Berkus writes:
> > ***15,000***? I'd say that someone has an application design issue.
> > Fixing the stack overflow is a good thing, but that query is never going
> > to return ...
>
Just for the record, it does finish in 5 sec on my la
This situation falls from a problem that we noticed a mighty long time ago
in Slony, where the set of XIDs outstanding gets very large, and, attendant
to that, the set of "action id" values by which tuples are being filtered,
gets correspondingly large.
It happens when there is a long pause in app
Josh Berkus writes:
> ***15,000***? I'd say that someone has an application design issue.
> Fixing the stack overflow is a good thing, but that query is never going
> to return ...
Yeah, the parser's stack consumption seems like only the tip of the
iceberg here.
I find it hard to visualize a us
On 05/25/2013 09:56 AM, Gurjeet Singh wrote:
> When Postgres encounters a long list of AND/OR chains, it errors out at
> check_stack_depth() after a limit of few thousand. At around 10,000
> elements, the recursion at assign_expr_collations() causes the error. But
> at a little higher element count
On Sat, May 25, 2013 at 9:56 AM, Gurjeet Singh wrote:
> When Postgres encounters a long list of AND/OR chains, it errors out at
> check_stack_depth() after a limit of few thousand. At around 10,000
> elements, the recursion at assign_expr_collations() causes the error. But
> at a little higher el
10 matches
Mail list logo
