On 11/8/17 18:48, Simon Riggs wrote:
> What would happen if some of the INSERTs failed? Where would control
> go to? (Maybe this is just "no change" in this particular proc)
An exception is raised and unless the exception is caught (depending on
the PL), control leaves the procedure. What is already committed stays.
> What happens if the procedure is updated during execution? Presumably
> it keeps executing the original version as seen in the initial
> snapshot?
correct
> Does the xmin of this session advance after each transaction, or do we
> hold the snapshot used for the procedure body open, causing us to hold
> back xmin and prevent vacuuming from being effective?
>
> What would happen if a procedure recursively called itself? And yet it
> was updated half-way through? Would that throw an error (I think it
> should).
I don't think anything special happens here. The snapshot that is used
to read the procedure source code and other meta information is released
at a transaction boundary.
>> 3) The PL implementations themselves allocate memory in
>> transaction-bound contexts for convenience as well. This is usually
>> easy to fix by switching to PortalContext as well. As you see, the
>> PL/Python code part of the patch is actually very small. Changes in
>> other PLs would be similar.
>
> Is there some kind of interlock to prevent dropping the portal half way thru?
I should probably look this up, but I don't think this is fundamentally
different from how VACUUM and CREATE INDEX CONCURRENTLY run inside a
portal and issue multiple transactions in sequence.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
