Tom Lane wrote:
Well, you're not right ...
That's true. This time it was my own fault altogether I'm afraid.
Regards,
Thomas Hallgren
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> It's my PL/Java test framework that fails so it's a bit complex but if
> I'm right, any immutable, set-returning function that allocates stuff in
> multi_call_memory_context at first call and then reused it, should show
> the same problem.
Well, you
Tom Lane wrote:
What life span does the context->multi_call_memory_context have in case
of IMMUTABLE functions that returns SETOF?
It should be long enough. What's your test case exactly?
It's my PL/Java test framework that fails so it's a bit complex but if
I'm right, any immutable, set
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> What life span does the context->multi_call_memory_context have in case
> of IMMUTABLE functions that returns SETOF?
It should be long enough. What's your test case exactly?
regards, tom lane
---(end
After some pretty tedious assembly debugging I've managed to locate the
source of my problem. It is probably similar to a bug involving
MemoryContext life cycle on IMMUTABLE functions that I struggled with
last winter (later fixed by Tom).
This is what happens:
I have an function declared as IM
Hi,
I have an intermittent bug in PL/Java that only shows up on Win32. Is
there any way of debugging the postgres.exe process that corresponds to
your connection on a win32 (MinGW) platform?
I have a MinGW environment with gdb but I can't figure out how to make
gdb attach to a running process i
