thanks for the response Tom=2C I think the GP consultant made a mistake tho=
ugh=2C he should have wrote "unrecognized node"...but then again=2C I'm not=
privy to the GP-side trace-output logs=2C I'll check with him on that...st=
ill can't believe they think it's an ODBC error..
=20
I saw the actual code you were referring to in utility.c=2C and the default=
for the CASE statement at the end=2C right along with the "unrecognized no=
de type %d" error output message. I'm sure it's some bug/outdated bin on t=
he GP side..I can't see how a SELECT statement against a DB would cause a s=
kipped record=2C under any type of log setting in a DB
=20
Thank you again=2C to both of you for the responses...really appreciate it =
a 'bunch=2C very helpful..
=20
> From: tgl@sss.pgh.pa.us
> To: mark.kirkwood@catalyst.net.nz
> CC: deanelliotdeloach@hotmail.com=3B michael.paquier@gmail.com=3B pgsql-b=
ugs@postgresql.org
> Subject: Re: [BUGS] BUG #12749: WARNING: unrecognized node type: 701
> Date: Tue=2C 10 Feb 2015 10:14:37 -0500
>=20
> Mark Kirkwood <mark.kirkwood@catalyst.net.nz> writes:
> > On 10/02/15 16:54=2C dean deloach wrote:
> >> Thanks for the response guys=2C really appreciate it. Turns out=2C it=
has
> >> something to do with the log_statement config parameter on the DB. Th=
e
> >> 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=2C fo=
r
> >> different log_statement config values:
> >>=20
> >>=20
> >> log_statement=3Dall - returns n records=2C no errors logged in Greenp=
lum
> >> log file
> >>=20
> >> log_statement=3Dnone - returns n records=2C no errors logged in Green=
plum
> >> log file
> >>=20
> >> log_statement=3Dmod - returns n-1 records=2C "unknown node: 701" erro=
r
> >> logged in Greenplum log file
> >>=20
> >> log_statement=3Dddl - returns n-1 records=2C "unknown node: 701" erro=
r
> >> logged in Greenplum log file
> >>=20
>=20
> > That is pretty scary - I'd still recommend raising it with Pivotal -=20
> > logging options changing the results of queries is ...*unexpected*...to=
=20
> > put it mildly!
>=20
> Given the described behavior=2C I'd bet a lot that it means somebody
> missed a case in GetCommandLogLevel(). Which makes it annoying=2C but
> not especially scary except for the fact that the failure is causing
> it to abort the user query too soon.
>=20
> FWIW=2C the phrase "unknown node" does not appear in the community Postgr=
es
> sources=2C either now or back in 8.2=3B it would violate our message styl=
e
> guidelines to write it like that. So this is coming from some
> Greenplum-added code=2C and you definitely have to talk to them about it.
>=20
> regards=2C tom lane
=