Thread: Strange server error with current 8.0beta driver

Strange server error with current 8.0beta driver

From
"Barry Lind"
Date:
During my testing with the 8.0 driver, I am occasionally getting
failures.  The strange thing is that a test will only fail 1 out of 10
times.  The error I am getting from the server is:

ERROR:  unrecognized node type: 25344832

(the number in the message varies).  Does anyone know what this server
error means?  I don't have the server source code installed right now to
look it up.

Also, I don't see these errors with the 7.4 driver.  So I suspect
something in the V3 protocol path is triggering this error.

Thanks,
--Barry



Re: Strange server error with current 8.0beta driver

From
Kris Jurka
Date:

On Fri, 19 Nov 2004, Barry Lind wrote:

> During my testing with the 8.0 driver, I am occasionally getting
> failures.  The strange thing is that a test will only fail 1 out of 10
> times.  The error I am getting from the server is:
>
> ERROR:  unrecognized node type: 25344832

This type of error points to a bug in the server.  It means a query plan
is created that it can't process.  A higher level node finds a lower level
node that it doesn't expect.  The variability of the test failure could be
due to different plans being generated (note that V2 vs V3 can generate
different plans because of string substitution vs a prepared query).  The
fact that the node number varies is a little suspicious, also because it's
a very large value.  Does it vary between a couple values or is it
different every time.  If it varies wildly then that could point to a
memory overwrite instead of a bad plan being created, but in any case this
problem is on the server side.

Kris Jurka


Re: Strange server error with current 8.0beta driver

From
Tom Lane
Date:
Kris Jurka <books@ejurka.com> writes:
> On Fri, 19 Nov 2004, Barry Lind wrote:
>> ERROR:  unrecognized node type: 25344832

> This type of error points to a bug in the server.

Right.  Could we see a test case?

If you did not build the server with --enable-cassert, try doing so;
that will probably make the error more reproducible.  I suspect that
you've found a problem with dangling pointers or some such, and the
variability depends on whether the referenced memory has been re-used
yet.  --enable-cassert turns on code to wipe freed memory immediately,
so it should make it easier to track down the query that causes this.

            regards, tom lane

Re: Strange server error with current 8.0beta driver

From
"Barry Lind"
Date:
Kris,

Environment #1:  WinXP 8.0beta4 server, 8.0jdbc client

I get random failures with the following errors:
$ grep ERROR postgresql-2004-11-19_091524.log
2004-11-19 12:19:06 ERROR:  unrecognized node type: 25344832
2004-11-19 12:20:06 ERROR:  unrecognized node type: 25344832
2004-11-19 12:21:06 ERROR:  unrecognized node type: 0
2004-11-19 12:22:06 ERROR:  unrecognized node type: 0
2004-11-19 12:23:06 ERROR:  unrecognized node type: 0
2004-11-19 12:24:06 ERROR:  unrecognized node type: 0
2004-11-19 12:25:06 ERROR:  unrecognized node type: 0
2004-11-19 12:26:06 ERROR:  unrecognized node type: 0
2004-11-19 12:27:06 ERROR:  unrecognized node type: 0
2004-11-19 12:28:06 ERROR:  unrecognized node type: 653
2004-11-19 12:29:06 ERROR:  unrecognized node type: 0
2004-11-19 12:30:06 ERROR:  unrecognized node type: 0
2004-11-19 12:30:30 ERROR:  unrecognized node type: 26
2004-11-19 12:31:06 ERROR:  unrecognized node type: 0
2004-11-19 12:32:06 ERROR:  unrecognized node type: 0
2004-11-19 12:33:06 ERROR:  unrecognized node type: 0
2004-11-19 12:34:06 ERROR:  unrecognized node type: 0
2004-11-19 12:35:06 ERROR:  unrecognized node type: 0
2004-11-19 12:36:06 ERROR:  unrecognized node type: 0
2004-11-19 12:37:06 ERROR:  unrecognized node type: 0


Environment #2:  Sun Solaris 7.4.3 server, 8.0jdbc client

I get random failures with the following errors:
ERROR: no value found for parameter 1
ERROR: no value found for parameter 1
ERROR: no value found for parameter 1
ERROR: no value found for parameter 1
ERROR: no value found for parameter 1
ERROR: no value found for parameter 1
ERROR: no value found for parameter 1


I am seeing errors in the two different environments where I am testing
the 8.0 driver (which fully uses the V3 protocol), I don't have errors
with the 7.4 driver (which only used basic V3 protocol features).  I
will work to try to come up with a smaller reproducable test case and
repro in a linux environment where I can do more.

Thanks,
--Barry


-----Original Message-----
From: Kris Jurka [mailto:books@ejurka.com]
Sent: Friday, November 19, 2004 3:57 PM
To: Barry Lind
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] Strange server error with current 8.0beta driver



On Fri, 19 Nov 2004, Barry Lind wrote:

> During my testing with the 8.0 driver, I am occasionally getting
> failures.  The strange thing is that a test will only fail 1 out of 10

> times.  The error I am getting from the server is:
>
> ERROR:  unrecognized node type: 25344832

This type of error points to a bug in the server.  It means a query plan
is created that it can't process.  A higher level node finds a lower
level node that it doesn't expect.  The variability of the test failure
could be due to different plans being generated (note that V2 vs V3 can
generate different plans because of string substitution vs a prepared
query).  The fact that the node number varies is a little suspicious,
also because it's a very large value.  Does it vary between a couple
values or is it different every time.  If it varies wildly then that
could point to a memory overwrite instead of a bad plan being created,
but in any case this problem is on the server side.

Kris Jurka



Re: Strange server error with current 8.0beta driver

From
Oliver Jowett
Date:
Barry Lind wrote:

> Environment #1:  WinXP 8.0beta4 server, 8.0jdbc client
> 2004-11-19 12:19:06 ERROR:  unrecognized node type: 25344832

> Environment #2:  Sun Solaris 7.4.3 server, 8.0jdbc client
> ERROR: no value found for parameter 1

 From memory the 7.4.3 behaviour you see can happen if you DECLARE
CURSOR with a parameterized query (executes OK) then try to FETCH from
it (fails with the above error, as the original parameter values from
DECLARE execution are not stored with the portal). The parameterization
can happen either via V3 protocol Parse/Bind or via function execution,
IIRC.

I put together a patch to fix this that made it into 8.0 (with some
changes IIRC), perhaps the bug lies in there somewhere.

-O