"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: http://www.postgresql.org/mailpref/pgsql-hackers