On Sat, 7 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql)
Right, because the bug was in exec_bind_message, which you can't inv
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> And the java program crashing the backend is attached. (it is generally
> one prepared statement , which i didn't succeded to crash from psql)
Right, because the bug was in exec_bind_message, which you can't invoke
from psql :-(. Fixed, but we re
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> As I did before, I send the strace ouput showing what jdbc is sending to the
> backend.
Thanks. I've been able to reproduce it now, and I think the plan is
actually OK, but for some reason the wrong rtable list is getting sent
along to the execut
Tom Lane <[EMAIL PROTECTED]> writes:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
>> I've found a bug with 8.2beta1:
>
> Can you put together a self-contained test case for this? The planner
> is evidently generating an incorrect plan from that messy view, but
> trying to reverse-engineer th
On Sat, 7 Oct 2006, Sergey E. Koposov wrote:
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql) (it's
possible to rewrite it in C with libpq, but I cannot do that very easily).
As I did before, I send t
On Sat, 7 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Whatever makes it crash ;-)
So, the database schema with little data and a few functions is here
http://lnfm1.sai.msu.ru/~math/public
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Whatever makes it crash ;-)
My guess is that there's some rewriter interaction involved, which means
that the rule itself is part of the problem --- you'll likely not be
abl
On Sat, 7 Oct 2006, Sergey E. Koposov wrote:
cas=# explain UPDATE table_list SET description = 'tag{image
SRC="/vizier/new2.gif"}3rd release of DENIS (2005Sep)' WHERE id =
cas_get_table_id ('cas_data_sega','b_denis_denis5' );
QUERY PLAN
On Sat, 7 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
I'll try, but it will be quite hard.
is evidently generating an incorrect plan from that messy view, b
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
is evidently generating an incorrect plan from that messy view, but
trying to reverse-engineer the complete scenario from what you've told
us loo
Hello -hackers,
I've found a bug with 8.2beta1:
1) Log message:
LOG: duration: 9.144 ms bind : UPDATE table_list SET description
= $1 WHERE id = cas_get_table_id ( $2,$3 )
DETAIL: parameters: $1 = '\tag{image SRC="/vizier/new2.gif"}3rd release of
DENIS (2005Sep)', $2 = 'cas_data_sega', $3 =
11 matches
Mail list logo
