unrecognized node type: 350
Hello, We have upgraded postgresql from version 12 to 13.8 and after that facing unrecognized node type: 350, what could be the issue? 2022-11-16 02:28:08,957 DEBUG Logger#insert - 2022-11-16-02:28:08 - ERROR - 2022-11-16-02:28:08 - org.postgresql.util.PSQLException: ERROR: unrecognized node type: 350 -- Shashidhar
Re: PostgreSQL server "idle in transaction"
El día Dienstag, November 15, 2022 a las 10:28:11 -0500, Tom Lane escribió: > Adrian Klaver writes: > > On 11/15/22 04:28, Matthias Apitz wrote: > >> I have below the full ESQL/C log and do not understand, why the > >> PostgreSQL server is thinking "idle in transaction". For me with the > >> "COMMIT" on the line below marked with ^ the transaction was closed. > > > From your log: > > > [6978] [15.11.2022 11:05:50:172]: ECPGtrans on line 1211: action > > "commit"; connection "testdb" > > ^^ > > [6978] [15.11.2022 11:05:50:173]: ecpg_execute on line 543: query: > > select name from pg_cursors where name = $1 ; with 1 parameter(s) on > > connection testdb > > > So that query is being executed after the COMMIT. > > Right. By default, ecpg would start a new transaction block for that. > See > > https://www.postgresql.org/docs/current/ecpg-commands.html#ECPG-TRANSACTIONS > Thank you. This page makes it clear why the last search started a transaction, which at the end is pending due to a missing COMMIT. On the other hand, when we would set EXEC SQL SET AUTOCOMMIT TO ON, when does the transaction block starts exactly (which could be rolled back), as there is no EXEC SQL BEGIN? Thanks again matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: unrecognized node type: 350
Any help on this? On Wed, 16 Nov, 2022, 1:53 pm shashidhar Reddy, < shashidharreddy...@gmail.com> wrote: > Hello, > > We have upgraded postgresql from version 12 to 13.8 and after that facing > unrecognized > node type: 350, what could be the issue? > > 2022-11-16 02:28:08,957 DEBUG Logger#insert - 2022-11-16-02:28:08 - ERROR - > 2022-11-16-02:28:08 - org.postgresql.util.PSQLException: ERROR: unrecognized > node type: 350 > > -- > Shashidhar >
Re: pg_restore remap schema
Hi, I worked on the pg_dump source code to add remap schema functionality to use it internally where I work. This is a first version that allows to remap tables, views and sequences (only to export schema). Is this development likely to interest the PG community and to continue this development further? Regards, Fabrice On Mon, Aug 8, 2022 at 8:22 PM Tom Lane wrote: > Guillaume Lelarge writes: > > Le lun. 8 août 2022 à 18:28, Fabrice Chapuis a > >> Is a development in progress to add this option > > > Nope, never heard of someone working on this. > > People have asked for such a thing before, but it'd be quite difficult > to do reliably --- particularly inside function bodies, which aren't > normally parsed at all during a dump/restore. If you're willing to > accept a 95% solution, running the pg_restore output through "sed" > would likely work fairly well. I'd personally want to diff the > before-and-after scripts before applying though :-) > > regards, tom lane >
Re: PostgreSQL server "idle in transaction"
El día Dienstag, November 15, 2022 a las 10:28:11 -0500, Tom Lane escribió: > Adrian Klaver writes: > > On 11/15/22 04:28, Matthias Apitz wrote: > >> I have below the full ESQL/C log and do not understand, why the > >> PostgreSQL server is thinking "idle in transaction". For me with the > >> "COMMIT" on the line below marked with ^ the transaction was closed. > > > From your log: > > > [6978] [15.11.2022 11:05:50:172]: ECPGtrans on line 1211: action > > "commit"; connection "testdb" > > ^^ > > [6978] [15.11.2022 11:05:50:173]: ecpg_execute on line 543: query: > > select name from pg_cursors where name = $1 ; with 1 parameter(s) on > > connection testdb > > > So that query is being executed after the COMMIT. > > Right. By default, ecpg would start a new transaction block for that. > See > > https://www.postgresql.org/docs/current/ecpg-commands.html#ECPG-TRANSACTIONS > Additional question: We're using COMMIT to commit data changes or deletions into the database. What is the technical impact of such backends sitting with "idle in transaction" because the application after doing some work and now waiting for new work, have done before going to wait such queries for open cursors without any result? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: unrecognized node type: 350
> On 16 Nov 2022, at 09:23, shashidhar Reddy > wrote: > We have upgraded postgresql from version 12 to 13.8 and after that facing > unrecognized node type: 350, what could be the issue? > 2022-11-16 02:28:08,957 DEBUG Logger#insert - 2022-11-16-02:28:08 - ERROR - > 2022-11-16-02:28:08 - org.postgresql.util.PSQLException: ERROR: unrecognized > node type: 350 Are you running a version of JDBC which supports postgres 13? -- Daniel Gustafsson https://vmware.com/
Re: pg_restore remap schema
Hi, Le mer. 16 nov. 2022 à 13:08, Fabrice Chapuis a écrit : > Hi, > I worked on the pg_dump source code to add remap schema functionality to > use it internally where I work. This is a first version that allows to > remap tables, views and sequences (only to export schema). Is this > development likely to interest the PG community and to continue this > development further? > > If it doesn't work on functions, that will be a big issue. And to be honest, I don't think you can do it reliably on functions, especially with dynamic queries in PL/pgsql. Though it would still be interesting to see your patch. -- Guillaume.
Re: unrecognized node type: 350
We are using 42.2.21 jdbc version On Wed, 16 Nov, 2022, 6:26 pm Daniel Gustafsson, wrote: > > On 16 Nov 2022, at 09:23, shashidhar Reddy > wrote: > > > We have upgraded postgresql from version 12 to 13.8 and after that > facing unrecognized node type: 350, what could be the issue? > > 2022-11-16 02:28:08,957 DEBUG Logger#insert - 2022-11-16-02:28:08 - > ERROR - 2022-11-16-02:28:08 - org.postgresql.util.PSQLException: ERROR: > unrecognized node type: 350 > > Are you running a version of JDBC which supports postgres 13? > > -- > Daniel Gustafsson https://vmware.com/ > >
Re: An I/O error occured while sending to the backend
On 11/16/22 00:37, gzh wrote: Thank you very much for your advice. What I don't understand is that there is no problem when executing ① alone or ② alone, the error occurs when ① and ② are executed together . It works well when i let the application sleep after ① for 10 seconds before executing ② . Is this true for large numbers of lines in you csv? Originally you said something like 'adding 1000 lines' broke your app. Are you using CopyManager?
Re: unrecognized node type: 350
shashidhar Reddy writes: > We have upgraded postgresql from version 12 to 13.8 and after that > facing unrecognized > node type: 350, what could be the issue? What is the query that produces that? Do you have any extensions loaded in the server (auto_explain or the like)? regards, tom lane
Re: pg_restore remap schema
Guillaume Lelarge writes: > Le mer. 16 nov. 2022 à 13:08, Fabrice Chapuis a > écrit : >> I worked on the pg_dump source code to add remap schema functionality to >> use it internally where I work. This is a first version that allows to >> remap tables, views and sequences (only to export schema). Is this >> development likely to interest the PG community and to continue this >> development further? > If it doesn't work on functions, that will be a big issue. And to be > honest, I don't think you can do it reliably on functions, especially with > dynamic queries in PL/pgsql. Yeah --- I fear there is no hope of making a feature like this that works reliably enough that we'd accept it. pg_restore is just not that smart about what is in the chunks of DDL that it processes, and trying to make it smart enough is a losing game. regards, tom lane
Re: pg_restore remap schema
Hi And could it be at pg_dump level ? It seems more aware of what is doing... Stephane Le mer. 16 nov. 2022 à 15:42, Tom Lane a écrit : > Guillaume Lelarge writes: > > Le mer. 16 nov. 2022 à 13:08, Fabrice Chapuis > a > > écrit : > >> I worked on the pg_dump source code to add remap schema functionality to > >> use it internally where I work. This is a first version that allows to > >> remap tables, views and sequences (only to export schema). Is this > >> development likely to interest the PG community and to continue this > >> development further? > > > If it doesn't work on functions, that will be a big issue. And to be > > honest, I don't think you can do it reliably on functions, especially > with > > dynamic queries in PL/pgsql. > > Yeah --- I fear there is no hope of making a feature like this that > works reliably enough that we'd accept it. pg_restore is just not > that smart about what is in the chunks of DDL that it processes, > and trying to make it smart enough is a losing game. > > regards, tom lane > > > -- "Où se posaient les hirondelles avant l'invention du téléphone ?" -- Grégoire Lacroix
Re: pg_restore remap schema
=?UTF-8?Q?St=C3=A9phane_Tachoires?= writes: > And could it be at pg_dump level ? > It seems more aware of what is doing... pg_dump would be in a slightly better position, but only slightly. It still has no idea about the contents of function bodies. Also, if it's acceptable to do this at dump time, you could just temporarily rename the schema on the server while making the dump. (Not that that would fix function bodies either.) regards, tom lane
Re: pg_restore remap schema
Tom Lane schrieb am 08.08.2022 um 20:22: > Guillaume Lelarge writes: >> Le lun. 8 août 2022 à 18:28, Fabrice Chapuis a >>> Is a development in progress to add this option > >> Nope, never heard of someone working on this. > > People have asked for such a thing before, but it'd be quite difficult > to do reliably --- particularly inside function bodies, which aren't > normally parsed at all during a dump/restore. If you're willing to > accept a 95% solution, running the pg_restore output through "sed" > would likely work fairly well. I'd personally want to diff the > before-and-after scripts before applying though :-) FWIW Oracle's "remap_schema" for their DataPump tool doesn't do this inside triggers or functions either. It does not even adjust the schema for sequences used for default values of columns. So for users migrating from Oracle, this wouldn't be a surprise ;)
Re: unrecognized node type: 350
Tom, We have extensions like plpgsql_check and plprofiler. Below is the query log with errors 2022-11-16 02:28:08,957 DEBUG Logger#insert - 2022-11-16-02:28:08 - ERROR - 2022-11-16-02:28:08 - org.postgresql.util.PSQLException: ERROR: unrecognized node type: 350 Where: PL/pgSQL function ccmiexceptions.computetariffexceptions(integer,integer,integer,integer[]) line 9 at IF SQL statement "SELECT CCMIExceptions.ComputeTariffExceptions($1, $2, $3, $4);" PL/pgSQL function serviceexceptions.recomputeexception(character varying,integer,integer,integer,integer,integer[]) line 7 at EXECUTE SQL statement "SELECT ServiceExceptions.RecomputeException(exceptionRecord.rule, exceptionRecord.exceptionId, exceptionRecord.columnId, exceptionRecord.serviceTypeId, invoiceIdX, billIdsX)" PL/pgSQL function serviceexceptions.recomputeexceptions(integer,integer[],integer,integer[]) line 23 at PERFORM SQL statement "SELECT ServiceExceptions.RecomputeExceptions(invoiceIdX, NULL, serviceTypeIdX, categoryIdsX)" PL/pgSQL function serviceexceptions.recomputeinvoice(integer,integer,integer[]) line 3 at PERFORM[ERROR: unrecognized node type: 350 Where: PL/pgSQL function ccmiexceptions.computetariffexceptions(integer,integer,integer,integer[]) line 9 at IF SQL statement "SELECT CCMIExceptions.ComputeTariffExceptions($1, $2, $3, $4);" PL/pgSQL function serviceexceptions.recomputeexception(character varying,integer,integer,integer,integer,integer[]) line 7 at EXECUTE SQL statement "SELECT ServiceExceptions.RecomputeException(exceptionRecord.rule, exceptionRecord.exceptionId, exceptionRecord.columnId, exceptionRecord.serviceTypeId, invoiceIdX, billIdsX)" PL/pgSQL function serviceexceptions.recomputeexceptions(integer,integer[],integer,integer[]) line 23 at PERFORM SQL statement "SELECT ServiceExceptions.RecomputeExceptions(invoiceIdX, NULL, serviceTypeIdX, categoryIdsX)" PL/pgSQL function serviceexceptions.recomputeinvoice(integer,integer,integer[]) line 3 at PERFORM] (test-import-configuration - simple-pdf-splitflag.xml) 2022-11-16 02:28:08,965 ERROR XmlImport#processInvoice - ERROR: unrecognized node type: 350 On Wed, Nov 16, 2022 at 7:57 PM Tom Lane wrote: > shashidhar Reddy writes: > > We have upgraded postgresql from version 12 to 13.8 and after that > > facing unrecognized > > node type: 350, what could be the issue? > > What is the query that produces that? Do you have any extensions > loaded in the server (auto_explain or the like)? > > regards, tom lane > -- Shashidhar
Re: unrecognized node type: 350
shashidhar Reddy writes: > We have extensions like plpgsql_check and plprofiler. Hmm. My bet is that one of those needs an update. You could probably narrow things down by setting log_error_verbosity to "verbose" so that an error location shows in the postmaster log. regards, tom lane
Re: unrecognized node type: 350
Tom, I have upgraded them to latest version. I also used pg_upgrade check before upgrading the postures from 12 to 13. On Wed, 16 Nov, 2022, 9:32 pm Tom Lane, wrote: > shashidhar Reddy writes: > > We have extensions like plpgsql_check and plprofiler. > > Hmm. My bet is that one of those needs an update. You could > probably narrow things down by setting log_error_verbosity to > "verbose" so that an error location shows in the postmaster log. > > regards, tom lane >
Re: unrecognized node type: 350
shashidhar Reddy writes: > I have upgraded them to latest version. By "update" I meant "bug fix". Some bit of code within the server is failing to cope with a data structure it needs to cope with. But you need to identify what bit of code that is before you'll have any basis for filing a bug report. regards, tom lane
Re: unrecognized node type: 350
I could see an error in syslogs, I am not sure what it means. kernel: [93631.415790] postgres[86383]: segfault at 80 ip 7f07f3e3eefd sp 7fffcf1db500 error 4 in plpgsql_check.so[7f07f3e2e000+34000] On Wed, Nov 16, 2022 at 9:36 PM shashidhar Reddy < shashidharreddy...@gmail.com> wrote: > Tom, > > I have upgraded them to latest version. > I also used pg_upgrade check before upgrading the postures from 12 to 13. > > On Wed, 16 Nov, 2022, 9:32 pm Tom Lane, wrote: > >> shashidhar Reddy writes: >> > We have extensions like plpgsql_check and plprofiler. >> >> Hmm. My bet is that one of those needs an update. You could >> probably narrow things down by setting log_error_verbosity to >> "verbose" so that an error location shows in the postmaster log. >> >> regards, tom lane >> > -- Shashidhar
Re: unrecognized node type: 350
shashidhar Reddy writes: > I could see an error in syslogs, I am not sure what it means. > kernel: [93631.415790] postgres[86383]: segfault at 80 ip 7f07f3e3eefd > sp 7fffcf1db500 error 4 in plpgsql_check.so[7f07f3e2e000+34000] That would certainly suggest a problem in plpgsql_check. It might or might not be related to the node-type error. regards, tom lane
Re: PANIC: could not flush dirty data: Cannot allocate memory
Hi, On 2022-11-15 13:23:56 +0100, klaus.mailingli...@pernau.at wrote: > Filesystem is ext4. VM technology is mixed: VMware, KVM and XEN PV. Kernel > is 5.15.0-52-generic. > > We have not seen this with Ubutnu 18.04 and 20.04 (although we might not > have noticed it). Did this start after upgrading to 22.04? Or after a certain kernel upgrade? Do you use cgroups or such to limit memory usage of postgres? I'd be helpful to see /proc/meminfo from one of the affected instances. Greetings, Andres Freund
Re: PANIC: could not flush dirty data: Cannot allocate memory
Hi, On 2022-11-16 09:16:56 -0800, Andres Freund wrote: > On 2022-11-15 13:23:56 +0100, klaus.mailingli...@pernau.at wrote: > > Filesystem is ext4. VM technology is mixed: VMware, KVM and XEN PV. Kernel > > is 5.15.0-52-generic. > > > > We have not seen this with Ubutnu 18.04 and 20.04 (although we might not > > have noticed it). > > Did this start after upgrading to 22.04? Or after a certain kernel upgrade? > > Do you use cgroups or such to limit memory usage of postgres? > > I'd be helpful to see /proc/meminfo from one of the affected instances. Another interesting thing would be to know the mount and file system options for the FS that triggers the failures. E.g. tune2fs -l path/to/blockdev and grep path/to/blockdev /proc/mounts Greetings, Andres Freund
Re: PostgreSQL server "idle in transaction"
On 11/16/22 12:51 AM, Matthias Apitz wrote: El día Dienstag, November 15, 2022 a las 10:28:11 -0500, Tom Lane escribió: Adrian Klaver writes: On 11/15/22 04:28, Matthias Apitz wrote: I have below the full ESQL/C log and do not understand, why the PostgreSQL server is thinking "idle in transaction". For me with the "COMMIT" on the line below marked with ^ the transaction was closed. From your log: [6978] [15.11.2022 11:05:50:172]: ECPGtrans on line 1211: action "commit"; connection "testdb" ^^ [6978] [15.11.2022 11:05:50:173]: ecpg_execute on line 543: query: select name from pg_cursors where name = $1 ; with 1 parameter(s) on connection testdb So that query is being executed after the COMMIT. Right. By default, ecpg would start a new transaction block for that. See https://www.postgresql.org/docs/current/ecpg-commands.html#ECPG-TRANSACTIONS Thank you. This page makes it clear why the last search started a transaction, which at the end is pending due to a missing COMMIT. On the other hand, when we would set EXEC SQL SET AUTOCOMMIT TO ON, when does the transaction block starts exactly (which could be rolled back), as there is no EXEC SQL BEGIN? I don't use ecpg, but the docs mention: "The embedded SQL interface also supports autocommit of transactions (similar to psql's default behavior)" In psql: test_(postgres)(5432)=# select 1/0; ERROR: division by zero test_(postgres)(5432)=# rollback ; WARNING: there is no transaction in progress ROLLBACK test_(postgres)(5432)=# select 1/1; ?column? -- 1 versus explicit transaction: test_(postgres)(5432)=# begin ; BEGIN test_(postgres)(5432)=# select 1/0; ERROR: division by zero test_(postgres)(5432)=# select 1/1; ERROR: current transaction is aborted, commands ignored until end of transaction block test_(postgres)(5432)=# rollback ; ROLLBACK test_(postgres)(5432)=# select 1/1; ?column? -- 1 Thanks again matthias -- Adrian Klaver adrian.kla...@aklaver.com
Re: unrecognized node type: 350
Extension version is 2.2. Is anything need to be done? To fix this issue? On Wed, 16 Nov, 2022, 10:06 pm Tom Lane, wrote: > shashidhar Reddy writes: > > I could see an error in syslogs, I am not sure what it means. > > kernel: [93631.415790] postgres[86383]: segfault at 80 ip > 7f07f3e3eefd > > sp 7fffcf1db500 error 4 in plpgsql_check.so[7f07f3e2e000+34000] > > That would certainly suggest a problem in plpgsql_check. > It might or might not be related to the node-type error. > > regards, tom lane >
Re: unrecognized node type: 350
shashidhar Reddy writes: > Extension version is 2.2. Is anything need to be done? To fix this issue? You could start by getting the information I asked for, ie where is this error being thrown from according to log_error_verbosity=verbose. regards, tom lane
Re: unrecognized node type: 350
Hi st 16. 11. 2022 v 19:01 odesílatel shashidhar Reddy < shashidharreddy...@gmail.com> napsal: > Extension version is 2.2. Is anything need to be done? To fix this issue? > > On Wed, 16 Nov, 2022, 10:06 pm Tom Lane, wrote: > >> shashidhar Reddy writes: >> > I could see an error in syslogs, I am not sure what it means. >> > kernel: [93631.415790] postgres[86383]: segfault at 80 ip >> 7f07f3e3eefd >> > sp 7fffcf1db500 error 4 in plpgsql_check.so[7f07f3e2e000+34000] >> >> That would certainly suggest a problem in plpgsql_check. >> It might or might not be related to the node-type error. >> > The extension plpgsql_check does not contain this message. More in typical usage, the plpgsql_check is not active at runtime (but it depends on usage). Node with number 350 should be ParamRef Can you show source code of functions that fail? Can you show plpgsql_check configuration? Regards Pavel >> regards, tom lane >> >
Re: unrecognized node type: 350
Pavel Stehule 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 >>> 7f07f3e3eefd >>> sp 7fffcf1db500 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. > 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.) regards, tom lane
Re: unrecognized node type: 350
st 16. 11. 2022 v 19:52 odesílatel Tom Lane napsal: > Pavel Stehule 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 > >>> 7f07f3e3eefd > >>> sp 7fffcf1db500 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 >
Re: unrecognized node type: 350
Pavel, Plpgsql_check configured under postures 13 lib. If it us not enabled default how can I do it? On Thu, 17 Nov, 2022, 8:44 am Pavel Stehule, wrote: > > > st 16. 11. 2022 v 19:52 odesílatel Tom Lane napsal: > >> Pavel Stehule 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 >> >>> 7f07f3e3eefd >> >>> sp 7fffcf1db500 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 >> >
Re: unrecognized node type: 350
č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, > wrote: > >> >> >> st 16. 11. 2022 v 19:52 odesílatel Tom Lane napsal: >> >>> Pavel Stehule 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 >>> >>> 7f07f3e3eefd >>> >>> sp 7fffcf1db500 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 >>> >>
Re: unrecognized node type: 350
Show plpgsql_check.mode gives an error as unrecognized configuration parameter. We use plprofiler On Thu, 17 Nov, 2022, 10:55 am Pavel Stehule, 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, >> wrote: >> >>> >>> >>> st 16. 11. 2022 v 19:52 odesílatel Tom Lane napsal: >>> Pavel Stehule 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 >>> 7f07f3e3eefd >>> sp 7fffcf1db500 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 >>>
Re: unrecognized node type: 350
č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, > 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, >>> wrote: >>> st 16. 11. 2022 v 19:52 odesílatel Tom Lane napsal: > Pavel Stehule 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 > >>> 7f07f3e3eefd > >>> sp 7fffcf1db500 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 >
Re: unrecognized node type: 350
Ok, I will check. On Thu, 17 Nov, 2022, 11:35 am Pavel Stehule, 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, >> 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, wrote: > > > st 16. 11. 2022 v 19:52 odesílatel Tom Lane > napsal: > >> Pavel Stehule 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 >> >>> 7f07f3e3eefd >> >>> sp 7fffcf1db500 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 >> >
