| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Transaction control in procedures |
| Date: | 2017-11-17 15:16:39 |
| Message-ID: | 50c4509a-e075-43ec-a135-b868764104a7@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/16/17 18:35, Simon Riggs wrote:
> For the first two answers above the answer was "currently executing
> statement", yet the third answer seems to be the procedure. So that is
> a slight discrepancy.
That's the way function execution, or really any nested execution,
currently works.
> ISTM we would like
>
> 1) a way to cancel execution of a procedure
> 2) a way to set a timeout to cancel execution of a procedure
>
> as well as
>
> 1) a way to cancel execution of a statement that is running within a procedure
> 2) a way to set a timeout to cancel execution of a statement in a procedure
>
> Visibility of what a routine is currently executing is the role of a
> debugger utility/API.
That would probably be nice, but it would be an entirely separate
undertaking. In particular, getting insight into some kind of execution
stack would necessarily be language specific. We do have some of that
for PL/pgSQL of course.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2017-11-17 15:27:14 | PG10.1 autovac killed building extended stats |
| Previous Message | Ildus Kurbangaliev | 2017-11-17 15:08:53 | Re: Repetitive code in RI triggers |