"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
> Tom Lane <t...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to