On 09/20/18 00:44, Tom Lane wrote: > Chapman Flack <c...@anastigmatix.net> writes: >> Would it be unprecedented / be unreasonable / break anything for the >> install_jar function to simply force a CommandCounterIncrement >> at the end of step 1 (after its temporary snapshot has been popped, >> so the former/on-entry ActiveSnapshot gets the increment)? > > The risk you take there is changing the behavior of calling function(s). > >> DECISION TIME ... > >> 1. fiddle the loader to always pass read_only => false to SPI calls, >> regardless of the volatility of the function it is loading for. >> 2. leave the loader alone, and adjust install_jar (an infrequent >> operation) to do something heretical with its on-entry snapshot. > > I suspect #1 is less likely to have bad side-effects. But I've not > done any careful analysis.
Or, revisiting #2, what of install_jar first pushing a copied snapshot (the current active one? a new one from GetTransactionSnapshot?) and keeping that copy on the stack during both operations (loading the jar and executing the deployment commands, with a CommandCounterIncrement in between) and popping it before return? Would that alleviate the concern of changing calling functions' behavior? -Chap
