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

From shashidhar Reddy
Subject Re: unrecognized node type: 350
Date
Msg-id CAH=zU4tgz1kKXc3sYQOwR54aqZz7J_EsowQpzcneb4_8zVBxzg@mail.gmail.com
Whole thread Raw
In response to Re: unrecognized node type: 350  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: unrecognized node type: 350  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-general
Pavel,

I just dropped the extension, thats where I got the second error. 
Looks like when any plpgsql functions runs it us looking for plpgsql_check.

On Thu, 17 Nov, 2022, 7:28 pm Pavel Stehule, <pavel.stehule@gmail.com> wrote:


čt 17. 11. 2022 v 13:32 odesílatel shashidhar Reddy <shashidharreddy001@gmail.com> napsal:
If I remove plpgsql_check getting below error
26: ERROR:  58P01: could not access file "$libdir/plpgsql_check": No such file or directory
LOCATION:  internal_load_library, dfmgr.c:211

If I drop only the extension (plpgsql_check) getting below error
psql:install.sql:122: ERROR:  function plpgsql_check_function(oid) does not exist
LINE 1: SELECT p.oid, n.nspname, p.proname, plpgsql_check_function(p...

you should to remove plpgsql_check by DROP EXTENSION plpgsql_check (only this way). plpgsql_check is just language checker. Why it is called by your application?

 
                                            ^

On Thu, Nov 17, 2022 at 11:52 AM shashidhar Reddy <shashidharreddy001@gmail.com> wrote:
Ok, I will check. 

On Thu, 17 Nov, 2022, 11:35 am Pavel Stehule, <pavel.stehule@gmail.com> wrote:


čt 17. 11. 2022 v 6:55 odesílatel shashidhar Reddy <shashidharreddy001@gmail.com> napsal:
Show plpgsql_check.mode  gives an error as unrecognized configuration parameter.

We use plprofiler 

it can be plprofiler issue, or maybe some problem when plpgsql_check is used with plprofiler together

can you execute following scenarios

1. uninstall plpgsql_check and check if you can get the exception

2. install plpgsql_check and uninstall plprofiler, and check the issue

3. try to install debug symbols and send to us stack trace.

Regards

Pavel
 

On Thu, 17 Nov, 2022, 10:55 am Pavel Stehule, <pavel.stehule@gmail.com> wrote:


čt 17. 11. 2022 v 6:18 odesílatel shashidhar Reddy <shashidharreddy001@gmail.com> napsal:
Pavel,

Plpgsql_check configured under postures 13 lib.

If it us not enabled default how can I do it?

Do you use profiler or tracer or passive mode from plpgsql_check?

What is result of "show plpgsql_check.mode" ?




On Thu, 17 Nov, 2022, 8:44 am Pavel Stehule, <pavel.stehule@gmail.com> wrote:


st 16. 11. 2022 v 19:52 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> st 16. 11. 2022 v 19:01 odesílatel shashidhar Reddy <
> shashidharreddy001@gmail.com> napsal:
>>> I could see an error in syslogs, I am not sure what it means.
>>> kernel: [93631.415790] postgres[86383]: segfault at 80 ip
>>> 00007f07f3e3eefd
>>> sp 00007fffcf1db500 error 4 in plpgsql_check.so[7f07f3e2e000+34000]

> The extension plpgsql_check does not contain this message.

Well, no --- it's the kernel reporting a segfault in plpgsql_check.

Although now that you mention it, there should also be traces of this
crash in the Postgres log; it would be interesting to see what's
reported there.

plpgsql_check can be used as a profiler or tracer too. But this functionality is not enabled by default.

So usually at runtime, the plpgsql_check is not active. So it can be nice to get plpgsql_check configuration and stack trace.
 

> Node with number 350 should be ParamRef

This is v13, so if I wrangled gdb correctly 350 is FuncCall.  (One
thing I'm wondering though is if the extension somehow got compiled
against wrong-version headers.  But you'd expect that it largely
wouldn't work at all if so.)

I did error in calculation, it is FuncCall

Regards

Pavel
 

                        regards, tom lane


--
Shashidhar

pgsql-general by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: unrecognized node type: 350
Next
From: Pavel Stehule
Date:
Subject: Re: unrecognized node type: 350