proposal - plpgsql unique statement id

On 13/11/2018 14:35, Pavel Stehule wrote:

I am try to enhance plpgsql_check about profiler functionality and I
have to solve how to identify every plpgsql statement across different
sessions. There is lineno, but surely it should not be unique. I propose
introduce stmtid to every statement structure. This number will be
unique inside function.

That seems reasonable enough, although I wouldn't use 0 as a valid stmtid.

A documenting comment near PLpgSQL_stmt might be nice.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pá 4. 1. 2019 v 13:58 odesílatel Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> napsal:

On 13/11/2018 14:35, Pavel Stehule wrote:

I am try to enhance plpgsql_check about profiler functionality and I
have to solve how to identify every plpgsql statement across different
sessions. There is lineno, but surely it should not be unique. I propose
introduce stmtid to every statement structure. This number will be
unique inside function.

That seems reasonable enough, although I wouldn't use 0 as a valid stmtid.

done

A documenting comment near PLpgSQL_stmt might be nice.

done

Regards

Pavel

On 04/01/2019 15:07, Pavel Stehule wrote:

pá 4. 1. 2019 v 13:58 odesílatel Peter Eisentraut
<peter.eisentraut@2ndquadrant.com
<mailto:peter.eisentraut@2ndquadrant.com>> napsal:

On 13/11/2018 14:35, Pavel Stehule wrote:

I am try to enhance plpgsql_check about profiler functionality and I
have to solve how to identify every plpgsql statement across different
sessions. There is lineno, but surely it should not be unique. I

propose

introduce stmtid to every statement structure. This number will be
unique inside function.

That seems reasonable enough, although I wouldn't use 0 as a valid
stmtid.

done

Related, should stmtid be unsigned int rather than signed int?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pá 18. 1. 2019 v 8:56 odesílatel Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> napsal:

On 04/01/2019 15:07, Pavel Stehule wrote:

pá 4. 1. 2019 v 13:58 odesílatel Peter Eisentraut
<peter.eisentraut@2ndquadrant.com
<mailto:peter.eisentraut@2ndquadrant.com>> napsal:

On 13/11/2018 14:35, Pavel Stehule wrote:

I am try to enhance plpgsql_check about profiler functionality and

I

have to solve how to identify every plpgsql statement across

different

sessions. There is lineno, but surely it should not be unique. I

propose

introduce stmtid to every statement structure. This number will be
unique inside function.

That seems reasonable enough, although I wouldn't use 0 as a valid
stmtid.

done

Related, should stmtid be unsigned int rather than signed int?

done

Regards

Pavel

There are still a handful of places where a statement is created but no
stmtid is assigned. Can you check those?

src/pl/plpgsql/src/pl_exec.c:2815
src/pl/plpgsql/src/pl_exec.c:4580
src/pl/plpgsql/src/pl_gram.y:907

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

út 22. 1. 2019 v 14:55 odesílatel Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> napsal:

There are still a handful of places where a statement is created but no
stmtid is assigned. Can you check those?

src/pl/plpgsql/src/pl_exec.c:2815
src/pl/plpgsql/src/pl_exec.c:4580

These statements are "fake" very short life statements without processing
via statement switch. Should not be counted, because are dynamically
created, dropped, and stmtid should be 0 or -1 (that means it should be int
again).
Now, for both cases, the stmtid is 0, due memset to 0.

src/pl/plpgsql/src/pl_gram.y:907

It was missing, fixed, thank you for check

Regards

Pavel

On 22/01/2019 19:04, Pavel Stehule wrote:

It was missing, fixed, thank you for check

committed

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

committed

Why didn't this patch modify the dumping logic in pl_funcs.c to print
the IDs? I'm not aware of other cases where we intentionally omit
fields from debug-support printouts.

regards, tom lane

čt 24. 1. 2019 v 23:08 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

committed

Why didn't this patch modify the dumping logic in pl_funcs.c to print
the IDs? I'm not aware of other cases where we intentionally omit
fields from debug-support printouts.

I had not a idea, so this field can be useful there. I'll send a patch with
it.

Regards

Pavel

čt 24. 1. 2019 v 23:08 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

committed

Why didn't this patch modify the dumping logic in pl_funcs.c to print
the IDs? I'm not aware of other cases where we intentionally omit
fields from debug-support printouts.

Currently we don't print lineno, what is maybe for user more important
information.

I looked to the code, and now I am thinking so it is little bit harder,
than I expected. Any new information can break output formatting

static void
dump_loop(PLpgSQL_stmt_loop *stmt)
{
dump_ind();
printf("LOOP\n");

dump_stmts(stmt->body);

dump_ind();
printf(" ENDLOOP\n");
}

can looks like

static void
dump_loop(PLpgSQL_stmt_loop *stmt, int stmtid_width)
{
dump_ind();
printf("%*d LOOP\n", stmtid_width, stmt->stmtid);

dump_stmts(stmt->body);

dump_ind();
printf(" ENDLOOP\n");
}

It is some what do you expect ?

Regards

Maybe more simple

static void
dump_loop(PLpgSQL_stmt_loop *stmt, int stmtid_width)
{
dump_ind();
printf("LOOP {%d}\n",stmt->stmtid);

dump_stmts(stmt->body);

dump_ind();
printf(" ENDLOOP\n");
}

Pavel