Re: unrecognized node type: 350

čt 17. 11. 2022 v 13:32 odesílatel shashidhar Reddy <
shashidharreddy001(at)gmail(dot)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(at)gmail(dot)com> wrote:
>
>> Ok, I will check.
>>
>> On Thu, 17 Nov, 2022, 11:35 am Pavel Stehule, <pavel(dot)stehule(at)gmail(dot)com>
>> wrote:
>>
>>>
>>>
>>> čt 17. 11. 2022 v 6:55 odesílatel shashidhar Reddy <
>>> shashidharreddy001(at)gmail(dot)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(dot)stehule(at)gmail(dot)com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> čt 17. 11. 2022 v 6:18 odesílatel shashidhar Reddy <
>>>>> shashidharreddy001(at)gmail(dot)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(dot)stehule(at)gmail(dot)com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> st 16. 11. 2022 v 19:52 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>>>>>>> napsal:
>>>>>>>
>>>>>>>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>>>>>>>> > st 16. 11. 2022 v 19:01 odesílatel shashidhar Reddy <
>>>>>>>> > shashidharreddy001(at)gmail(dot)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
>