Re: default_isolation_level='serializable' crashes on Windows

> "Kevin Grittner" wrote:
> Heikki Linnakangas wrote:
>> On 14.08.2012 14:25, Kevin Grittner wrote:

Attached is version 3.

>>> Oh, further testing this morning shows that while *queries* on
>>> the HS seem OK, streaming replication is now broken. I probably
>>> need to override transaction isolation on the recovery process.
>>> I'll take a look at that.
>>
>> Hmm, seems to work for me. Do you get an unexpected error or what?
>
> No, I wasn't getting errors in the clients or the logs, but I
> wasn't seeing data pop up on the replica when I expected. Perhaps I
> messed up my streaming replication configuration somehow.

Yeah, setup error. I accidentally dropped the primary_conninfo
setting from my recovery.conf file. Now that I've put that back, it
works just fine.

>> I didn't, I meant to point out that you can set
>> transaction_isolation just for the one transaction. But your
>> suggested hint is OK as well - you suggest to set it for the whole
>> session, which will also work around the problem. The "before the
>> first query in the transaction" isn't necessary in that case
>> though.

>> Yet another option is to suggest the "BEGIN ISOLATION LEVEL
>> REPEATABLE READ" syntax, instead of SET.
>
> I'm inclined toward hinting at a session override of the default.
> If you're typing away in psql, that's a lot less work. :-)

I tinkered with the messages (including correcting a reverse-logic
bug in which was displayed under what circumstances) and tweaked a
comment. I struggled with how to capitalize and quote. Let me know
what you think.

>>>>> Since the existing behavior is so bad, I'm inclined to think
>>>>> this merits backpatching to 9.1. Thoughts on that?
>>>>
>>>> Yes, we have to somehow fix the crash and the assertion failure
>>>> on 9.1.
>>>
>>> Should the check_transaction_read_only() stuff be back-patched to
>>> 9.1, too? So far as we know, that's fragile, not broken, right?
>>> Could the fix you envision there cause a behavioral change that
>>> could break anything that users might have in place?
>>
>> Good question. I don't see how it could cause a behavioral change,
>> but I've been wrong before.
>
> If we don't know of any actual existing bugs I'm inclined to not
> back-patch that part to 9.1, although it makes sense for 9.2 since
> we shouldn't be risking breakage of any production systems. I'm
> really cautious about giving anybody any excuse not to apply a
> minor update.

How about we fix the serializable versus HS & Windows bugs in one
patch, and then look at the other as a separate patch? If that's OK,
I think this is ready, unless my message text can be improved. (And
I will have a shot at my first back-patching....)

-Kevin