Thread: ERROR: unrecognized node type

ERROR: unrecognized node type

From
Amine Tengilimoglu
Date:
Hi;

  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?

image.png



Attachment

Re: ERROR: unrecognized node type

From
Tom Lane
Date:
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



Re: ERROR: unrecognized node type

From
Amine Tengilimoglu
Date:
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ı:
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

Re: ERROR: unrecognized node type

From
Adrian Klaver
Date:
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



Re: ERROR: unrecognized node type

From
Tom Lane
Date:
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



Re: ERROR: unrecognized node type

From
Tom Lane
Date:
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



Re: ERROR: unrecognized node type

From
Tomas Vondra
Date:

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



Re: ERROR: unrecognized node type

From
Amine Tengilimoglu
Date:
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/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

Re: ERROR: unrecognized node type

From
Tomas Vondra
Date:
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