[Bizgres-general] Statement Queuing take II - Resource Scheduling

[Mark Kirkwood]

Mark Kirkwood wrote:
>
> 1/ Identifying statement start and stop appears to be a little subtle, 
> as the code works with Lists of statements that are parsed and planned 
> and executed - we want to be careful not to take a lock for side-effect 
> statements such as triggered or selected SQL procedures (log_statement 
> and log_duration logic will help here). In addition cursors need to be 
> handled (suggest taking lock on the EXECUTE event, and holding the lock 
> across all the FETCHes until the cursor is closed)? Also some simple 
> sanity checking is required - we don't want to take a lock for 
> statements like BEGIN or COMMIT.
>   

I've been looking at this and made some progress. I'm thinking that the 
places to do this are:

1/ Simple query message receipt by the backend (exec_simple_query()).
2/ Execution message receipt by the backend (exec_execute_message()).

In both cases, the point to actually take the actual lock is immediately 
before the corresponding portal is run (i.e before the PortalRun() 
call). Similarly, the lock release will happen just after the portal is run.

This seems to work quite well, in that side-effect statements, functions 
and triggers do *not* cause us to re-take the locks.

Clients submitting multiple statements in one message *do* end up 
requesting the lock for each one in turn - this is ok I think, as it is 
in keeping with the way the backend works (i.e. a PortalRun() per 
*actual* statement).

Thoughts?

regards

Mark