Обсуждение: 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

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/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