"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Lastly, I simplified the added code in InitPostgres down to just a
>> bare assignment to XactIsoLevel. It doesn't seem worthwhile to
>> add all the cycles involved in SetConfigOption(), when we have no
>> desire to change the GUC permanently. (I think Kevin's code was
>> wrong anyway in that it was using PGC_S_OVERRIDE, which would
>> impact the reset state for the GUC.)
> Point taken on PGC_S_OVERRIDE. And that probably fixes the issue
> that caused me to hold up when I was about ready to pull the trigger
> this past weekend. A final round of testing showed a "SET" line on
> psql start, which is clearly wrong. I suspected that I needed to go
> to a lower level in setting that, but hadn't had a chance to sort
> out just what the right path was. In retrospect, just directly
> assigning the value seems pretty obvious.
Hm, I'm not sure why using SetConfigOption() would result in anything
happening client-side. (If this GUC were GUC_REPORT, that would result
in a parameter-change report to the client; but it isn't, and anyway
that shouldn't cause psql to print "SET".) Might be worth looking
closer at what was happening there.
>> Kevin, do you want to apply it? You had mentioned wanting some
>> practice with back-patches.
> I'm getting on a plane to Istanbul in less than 48 hours for the
> VLDB conference, and scrambling to tie up loose ends.
OK, I've committed it.
regards, tom lane
