Re: default_isolation_level='serializable' crashes on Windows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: heikki(dot)linnakangas(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: default_isolation_level='serializable' crashes on Windows
Date: 2012-08-24 17:13:45
Message-ID: 9356.1345828425@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Byrd 2012-08-24 18:24:48 Minor "pre-bug" in gram.y for DROP INDEX CONCURRENTLY IF_P EXISTS
Previous Message Shaun Thomas 2012-08-24 16:20:21 Loose Index Scans by Planner?