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
