ERROR: unrecognized node type

Amine Tengilimoglu <aminetengilimoglu@gmail.com> writes:

I am getting the "ERROR: unrecognized node type: 223" when I execute \d
combinations in psql and even when getting backup with pg_dump... probably
the same error will occur with other commands. What is causing this issue,
any idea? How to fix it?

You're not going to get any useful responses to that without more
details (at minimum, the server version). However, a reasonable
bet is that some stored view or expression contains a parse node
that some part of the server code is failing to cope with. We've
had such bugs in the past, but I don't know of any that are live
right now ... so maybe your answer is just "update to current
minor release".

If that doesn't help, it'd be good to try to isolate which database
object contains the problem, and then reconstruct what its definition
was, so we can try to understand where the oversight is.

regards, tom lane

I thought that the server version can be guess from the screenshot . I
already update the latest minor pg version and it didn't work :)

Thank you Tom.

Tom Lane <tgl@sss.pgh.pa.us>, 29 Eyl 2021 Çar, 20:16 tarihinde şunu yazdı:

On 9/29/21 10:54 AM, Amine Tengilimoglu wrote:

I thought that the server version can be guess from the screenshot . I

Unless folks are using plain text only email readers. That is why
screenshots are generally a bad idea for textual information. For the
record the Postgres version is 12.8.

already update the latest minor pg version and it didn't work :)

You will need to update with the actual minor version.

When you do the pg_dump, what is the error message?

Thank you Tom.

Tom Lane <tgl@sss.pgh.pa.us>, 29 Eyl 2021 Çar, 20:16 tarihinde şunu yazdı:

Amine Tengilimoglu <aminetengilimoglu@gmail.com> writes:

I am getting the "ERROR: unrecognized node type: 223" when I execute

\d

combinations in psql and even when getting backup with pg_dump...

probably

the same error will occur with other commands. What is causing this

issue,

any idea? How to fix it?

You're not going to get any useful responses to that without more
details (at minimum, the server version). However, a reasonable
bet is that some stored view or expression contains a parse node
that some part of the server code is failing to cope with. We've
had such bugs in the past, but I don't know of any that are live
right now ... so maybe your answer is just "update to current
minor release".

If that doesn't help, it'd be good to try to isolate which database
object contains the problem, and then reconstruct what its definition
was, so we can try to understand where the oversight is.

regards, tom lane

--
Adrian Klaver
adrian.klaver@aklaver.com

Amine Tengilimoglu <aminetengilimoglu@gmail.com> writes:

I thought that the server version can be guess from the screenshot . I
already update the latest minor pg version and it didn't work :)

Some of us aren't in the habit of loading images from external email,
especially not if they're broken attachments as this one was. (For
reference, it's not showing up in the PG archives.)

You're generally a lot better off *not* using screenshots to make
your point.

regards, tom lane

Adrian Klaver <adrian.klaver@aklaver.com> writes:

Unless folks are using plain text only email readers. That is why
screenshots are generally a bad idea for textual information. For the
record the Postgres version is 12.8.

Hmm, if it's v12 then NodeTag 223 is T_List, which is ... a bit
surprising. That's a common enough node type that "oversight"
doesn't seem to fly as an explanation.

I don't think we'll be able to make progress on this without a
lot more detail. A self-contained example that triggers it
would be very useful; or maybe you could get a backtrace from
the point of the error?

https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend

regards, tom lane

On 9/29/21 8:37 PM, Tom Lane wrote:

Adrian Klaver <adrian.klaver@aklaver.com> writes:

Unless folks are using plain text only email readers. That is why
screenshots are generally a bad idea for textual information. For the
record the Postgres version is 12.8.

Hmm, if it's v12 then NodeTag 223 is T_List, which is ... a bit
surprising. That's a common enough node type that "oversight"
doesn't seem to fly as an explanation.

I don't think we'll be able to make progress on this without a
lot more detail. A self-contained example that triggers it
would be very useful; or maybe you could get a backtrace from
the point of the error?

https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend

A handy trick for similar cases (not mentioned in the wiki) is to set

SET log_error_verbosity = verbose;

and then trigger the error. This logs the exact location (file:line)
where the error is printed, and then set a breakpoint to that place.
Makes it easier to generate the backtrace.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 9/29/21 8:37 PM, Tom Lane wrote:

Adrian Klaver <adrian.klaver@aklaver.com> writes:

Unless folks are using plain text only email readers. That is why
screenshots are generally a bad idea for textual information. For the
record the Postgres version is 12.8.

Hmm, if it's v12 then NodeTag 223 is T_List, which is ... a bit
surprising. That's a common enough node type that "oversight"
doesn't seem to fly as an explanation.

I don't think we'll be able to make progress on this without a
lot more detail. A self-contained example that triggers it
would be very useful; or maybe you could get a backtrace from
the point of the error?

https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend

A handy trick for similar cases (not mentioned in the wiki) is to set
SET log_error_verbosity = verbose;
and then trigger the error. This logs the exact location (file:line)
where the error is printed, and then set a breakpoint to that place.
Makes it easier to generate the backtrace.

Remarkable thing the related error occurs when executing sql statements
containing where. The sqls that do not contain a where are not getting an
error. Location information as below;

ERROR: XX000: unrecognized node type: 223
*LOCATION: exprType, nodeFuncs.c:263*
STATEMENT: SELECT n.nspname as "Schema",
c.relname as "Name",
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN
'm' THEN 'materialized view' WHEN 'i' THEN 'index' WHEN 'S' THEN 'sequence'
WHEN 's' THEN 'special' WHEN 'f' THEN 'foreign table' WHEN 'p' THEN
'partitioned table' WHEN 'I' THEN 'partitioned index' END as "Type",
pg_catalog.pg_get_userbyid(c.relowner) as "Owner"
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r','p','v','m','S','f','')
AND n.nspname <> 'pg_catalog'
AND n.nspname <> 'information_schema'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY 1,2;

Tomas Vondra <tomas.vondra@enterprisedb.com>, 30 Eyl 2021 Per, 00:10
tarihinde şunu yazdı:

On 9/30/21 8:38 AM, Amine Tengilimoglu wrote:

...
Remarkable thing  the related error occurs when executing sql
statements containing where.  The sqls that do not contain a where
are not getting an error. Location information as below;

ERROR:  XX000: unrecognized node type: 223
*LOCATION:  exprType, nodeFuncs.c:263*
STATEMENT:  SELECT n.nspname as "Schema",
          c.relname as "Name",
          CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view'
WHEN 'm' THEN 'materialized view' WHEN 'i' THEN 'index' WHEN 'S'
THEN 'sequence' WHEN 's' THEN 'special' WHEN 'f' THEN 'foreign
table' WHEN 'p' THEN 'partitioned table' WHEN 'I' THEN 'partitioned
index' END as "Type",
          pg_catalog.pg_get_userbyid(c.relowner) as "Owner"
        FROM pg_catalog.pg_class c
             LEFT JOIN pg_catalog.pg_namespace n ON n.oid =
c.relnamespace
        WHERE c.relkind IN ('r','p','v','m','S','f','')
              AND n.nspname <> 'pg_catalog'
              AND n.nspname <> 'information_schema'
              AND n.nspname !~ '^pg_toast'
          AND pg_catalog.pg_table_is_visible(c.oid)
        ORDER BY 1,2;

I'm unable to reproduce the issue, so it probably depends on what tables
are created etc. But if you say it only happens with WHERE clause,
that's interesting. It suggests the failure probably happens somewhere
in transformWhereClause, but we can only speculate why and the query
conditions look entirely reasonable.

I suggest you do this:

1) start a session, identify the PID of the backend

select pg_backend_pid();

2) attach a debugger (e.g. gdb) to the pid

gdb -p $PID

3) set breakpoint to the location in the error message

(gdb) break nodeFuncs.c:263
(gdb) continue

4) run the query, the breakpoint should be triggered

5) extract full backtrace

(gdb) bt full

6) print the expression

(gdb) p nodeToString(expr)

That should give us some hints about what might be wrong ...

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company