Re: ERROR: unrecognized node type

On 9/29/21 8:37 PM, Tom Lane wrote:
> Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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(dot)vondra(at)enterprisedb(dot)com>, 30 Eyl 2021 Per, 00:10
tarihinde şunu yazdı:

>
>
> On 9/29/21 8:37 PM, Tom Lane wrote:
> > Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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
>