Hello -hackers,
I've found a bug with 8.2beta1:
1) Log message:
LOG: duration: 9.144 ms bind unnamed: 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 =
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 looks
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, but
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
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
able to
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
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
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 the complete
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 executor.
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 really
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 invoke
11 matches
Mail list logo
