Re: BUG #17728: When jdbc calls the stored procedure, portal->stmts in FillPortalStore is null, causing a processing

On Thu, 22 Dec 2022 at 10:49, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference: 17728
> Logged by: When jdbc calls the stored procedure, portal-&gt;stmts
> in FillPortalStore is
> null, causing a processing
> Email address: dafoer_x(at)163(dot)com
> PostgreSQL version: 14.6
> Operating system: centos7.6 x86
> Description:
>
> REL_14_STABLE
> f489b480f4aa8b4db4858a7bef1b42c984992c8a
>
> Detail:
> #0 pgss_store (query=0x2d55138 "call p1($1)",
> queryId=16705933007615826313,
> query_location=1702063721, query_len=1763734642, kind=PGSS_EXEC,
> total_time=3341.1963460000002,
> rows=0, bufusage=0x7ffc2e4ddc20, walusage=0x7ffc2e4ddcf0, jstate=0x0)
> at
> pg_stat_statements.c:1225
> #1 0x00007f2254ebb72a in pgss_ProcessUtility (pstmt=0x2de8b98,
> queryString=0x2d55138 "call p1($1)", readOnlyTree=true,
> context=PROCESS_UTILITY_TOPLEVEL,
> params=0x2d55158, queryEnv=0x0, dest=0x2d59c08, qc=0x7ffc2e4dde60) at
> pg_stat_statements.c:1179
> #2 0x0000000000901273 in ProcessUtility (pstmt=0x2de8b98,
> queryString=0x2d55138 "call p1($1)", readOnlyTree=true,
> context=PROCESS_UTILITY_TOPLEVEL,
> params=0x2d55158, queryEnv=0x0, dest=0x2d59c08, qc=0x7ffc2e4dde60) at
> utility.c:523
> #3 0x00000000009001ea in PortalRunUtility (portal=0x2d99968,
> pstmt=0x2de8b98, isTopLevel=true, setHoldSnapshot=true, dest=0x2d59c08,
> qc=0x7ffc2e4dde60)
> at pquery.c:1155
> #4 0x00000000008fff53 in FillPortalStore (portal=0x2d99968,
> isTopLevel=true) at pquery.c:1028
> #5 0x00000000008ff913 in PortalRun (portal=0x2d99968,
> count=9223372036854775807, isTopLevel=true, run_once=true, dest=0x2d33ad8,
> altdest=0x2d33ad8,
> qc=0x7ffc2e4de070) at pquery.c:760
> #6 0x00000000008fb2a9 in exec_execute_message (portal_name=0x2d336a8 "",
> max_rows=9223372036854775807) at postgres.c:2187
> #7 0x00000000008fdf09 in PostgresMain (argc=1, argv=0x7ffc2e4de2a0,
> dbname=0x2d5d838 "postgres", username=0x2d311f8 "pg14") at postgres.c:4569
> #8 0x000000000084e6c7 in BackendRun (port=0x2d55690) at postmaster.c:4530
> #9 0x000000000084e04d in BackendStartup (port=0x2d55690) at
> postmaster.c:4252
> #10 0x000000000084a769 in ServerLoop () at postmaster.c:1745
> #11 0x000000000084a04a in PostmasterMain (argc=3, argv=0x2d2f150) at
> postmaster.c:1417
> #12 0x000000000075ac8a in main (argc=3, argv=0x2d2f150) at main.c:209
>
> (gdb) f 4
> #4 0x00000000008fff53 in FillPortalStore (portal=0x2d99968,
> isTopLevel=true) at pquery.c:1028
> 1028 PortalRunUtility(portal,
> linitial_node(PlannedStmt, portal->stmts),
> (gdb) p portal->stmts
> $1 = (List *) 0x0
>
> Because FillPortalStore uses dirty memory, pgss_store generates core when
> handling length（query_location=1702063721, query_len=1763734642）
> exceptions.
>
> My program：
> create or replace procedure p1(a inout int) as
> $$
> declare
> a int;
> begin
> select 1 into a;
> rollback;
> select 1 into a;
> commit;
> end;
> $$ language plpgsql;
>
> public static void main(String args[]) {
> Connection c = null;
> PreparedStatement ps;
> try {
> Class.forName("xxx");
> c =
> DriverManager.getConnection("jdbc:xxx://IP：PORT/postgres","user",
> "user(at)password");
> ps = c.prepareStatement("call p1(?)");
>
> for(int i = 0; i < 10;i++){
> ps.setObject(1, i);
> ps.execute();
> }
>
> } catch (Exception e) {
> System.err.println( e.getClass().getName()+": "+ e.getMessage() );
> System.exit(0);
> }
> System.out.println("test end");
> }
>
>
I just tried the same code with no issues.

Dave Cramer
www.postgres.rocks

>
>