čt 17. 11. 2022 v 15:02 odesílatel shashidhar Reddy < shashidharreddy...@gmail.com> napsal:
> 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. > Try to remove it - it does not sense on the production server. > On Thu, 17 Nov, 2022, 7:28 pm Pavel Stehule, <pavel.steh...@gmail.com> > wrote: > >> >> >> čt 17. 11. 2022 v 13:32 odesílatel shashidhar Reddy < >> shashidharreddy...@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 < >>> shashidharreddy...@gmail.com> wrote: >>> >>>> Ok, I will check. >>>> >>>> On Thu, 17 Nov, 2022, 11:35 am Pavel Stehule, <pavel.steh...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> čt 17. 11. 2022 v 6:55 odesílatel shashidhar Reddy < >>>>> shashidharreddy...@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.steh...@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> čt 17. 11. 2022 v 6:18 odesílatel shashidhar Reddy < >>>>>>> shashidharreddy...@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.steh...@gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> st 16. 11. 2022 v 19:52 odesílatel Tom Lane <t...@sss.pgh.pa.us> >>>>>>>>> napsal: >>>>>>>>> >>>>>>>>>> Pavel Stehule <pavel.steh...@gmail.com> writes: >>>>>>>>>> > st 16. 11. 2022 v 19:01 odesílatel shashidhar Reddy < >>>>>>>>>> > shashidharreddy...@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 >>> >>
