| From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
| Cc: | Amine Tengilimoglu <aminetengilimoglu(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org >> PG-General Mailing List" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: ERROR: unrecognized node type |
| Date: | 2021-09-29 21:10:06 |
| Message-ID: | b75d8a17-f1fd-3b5c-114b-1b98318fbd84@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ken Tanzer | 2021-09-29 23:23:11 | Capturing only queries with --echo-hidden option? |
| Previous Message | Tom Lane | 2021-09-29 18:37:16 | Re: ERROR: unrecognized node type |