> "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
hotstandby-serializable-3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers