Re: proposal - plpgsql unique statement id - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal - plpgsql unique statement id
Date
Msg-id CAFj8pRAn+gnOvN80z7aHumQypLQRARPf7JAfbc9jra5vHatu6g@mail.gmail.com
Whole thread Raw
In response to Re: proposal - plpgsql unique statement id  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: proposal - plpgsql unique statement id  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers


ú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



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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Thread-unsafe coding in ecpg
Next
From: Andres Freund
Date:
Subject: Re: Refactoring the checkpointer's fsync request queue