Re: ERROR: unrecognized node type - Mailing list pgsql-general

From Amine Tengilimoglu
Subject Re: ERROR: unrecognized node type
Date
Msg-id CADTdw-wtwq2qqQPZm5Nr3ZJSsLwhkVVnadjC1c0XnyZinaRX4A@mail.gmail.com
Whole thread Raw
In response to Re: ERROR: unrecognized node type  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: ERROR: unrecognized node type  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Ken Tanzer
Date:
Subject: Capturing only queries with --echo-hidden option?
Next
From: Masahiko Sawada
Date:
Subject: Re: Make bloom extension trusted, but can not drop with normal user