BUG #12749: WARNING: unrecognized node type: 701

On 09/02/15 13:04, deanelliotdeloach@hotmail.com wrote:

The following bug has been logged on the website:

Loading DB version:
PostgreSQL 8.2.15 (Greenplum Database 4.2.6.3 build 2)

It is probably best to raise this with Greenplum (Pivotal these days).

Cheers

Mark

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Tue, Feb 10, 2015 at 10:53 AM, Mark Kirkwood wrote:

On 09/02/15 13:04, deanelliotdeloach@hotmail.com wrote:

Loading DB version:
PostgreSQL 8.2.15 (Greenplum Database 4.2.6.3 build 2)

It is probably best to raise this with Greenplum (Pivotal these days).

Yup, there is nothing we can really do, and 8.2 is out of community
support since the end of 2011.
--
Michael

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Thanks for the response guys, really appreciate it. Turns out, it has something to do with the log_statement config parameter on the DB. The DBA changed and no one knew...these are the results we get when we attempt to pull data from the GP instance via Datadirect drivers, for different log_statement config values:

log_statement=all - returns n records, no errors logged in Greenplum log file log_statement=none - returns n records, no errors logged in Greenplum log file log_statement=mod - returns n-1 records, "unknown node: 701" error logged in Greenplum log file log_statement=ddl - returns n-1 records, "unknown node: 701" error logged in Greenplum log file Dean

On 10/02/15 16:54, dean deloach wrote:

Thanks for the response guys, really appreciate it. Turns out, it has
something to do with the log_statement config parameter on the DB. The
DBA changed and no one knew...these are the results we get when we
attempt to pull data from the GP instance via Datadirect drivers, for
different log_statement config values:

log_statement=all - returns n records, no errors logged in Greenplum
log file

log_statement=none - returns n records, no errors logged in Greenplum
log file

log_statement=mod - returns n-1 records, "unknown node: 701" error
logged in Greenplum log file

log_statement=ddl - returns n-1 records, "unknown node: 701" error
logged in Greenplum log file

That is pretty scary - I'd still recommend raising it with Pivotal -
logging options changing the results of queries is ...*unexpected*...to
put it mildly!

Cheers

Mark

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Mark Kirkwood <mark.kirkwood@catalyst.net.nz> writes:

On 10/02/15 16:54, dean deloach wrote:

Thanks for the response guys, really appreciate it. Turns out, it has
something to do with the log_statement config parameter on the DB. The
DBA changed and no one knew...these are the results we get when we
attempt to pull data from the GP instance via Datadirect drivers, for
different log_statement config values:

log_statement=all - returns n records, no errors logged in Greenplum
log file

log_statement=none - returns n records, no errors logged in Greenplum
log file

log_statement=mod - returns n-1 records, "unknown node: 701" error
logged in Greenplum log file

log_statement=ddl - returns n-1 records, "unknown node: 701" error
logged in Greenplum log file

That is pretty scary - I'd still recommend raising it with Pivotal -
logging options changing the results of queries is ...*unexpected*...to
put it mildly!

Given the described behavior, I'd bet a lot that it means somebody
missed a case in GetCommandLogLevel(). Which makes it annoying, but
not especially scary except for the fact that the failure is causing
it to abort the user query too soon.

FWIW, the phrase "unknown node" does not appear in the community Postgres
sources, either now or back in 8.2; it would violate our message style
guidelines to write it like that. So this is coming from some
Greenplum-added code, and you definitely have to talk to them about it.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

for sure, we have a bug open with Pivotal...the consultants we have are saying it's an Datadirect ODBC driver bug - WTF??? So when I SELECT from GP via ODBC, and by changing the log settings on the DB, I can get the DB to skip a record, and that's a bug with the calling function...??????

thanks for the response Tom, I think the GP consultant made a mistake though, he should have wrote "unrecognized node"...but then again, I'm not privy to the GP-side trace-output logs, I'll check with him on that...still can't believe they think it's an ODBC error..

I saw the actual code you were referring to in utility.c, and the default for the CASE statement at the end, right along with the "unrecognized node type %d" error output message. I'm sure it's some bug/outdated bin on the GP side..I can't see how a SELECT statement against a DB would cause a skipped record, under any type of log setting in a DB

Thank you again, to both of you for the responses...really appreciate it a 'bunch, very helpful..

Turns out, and engineer at Pivotal, Shawn Yan, sent out an email to our team, acknowledging that is a known bug with GP, when connecting via ODBC/JDBC, and that the workaround is in fact, to change the log_statement setting to either 'all' or 'none'
Dean