Re: [HACKERS] Transaction abortions & recovery handling
От | Ed Loehr |
---|---|
Тема | Re: [HACKERS] Transaction abortions & recovery handling |
Дата | |
Msg-id | 38C6ECA5.AA30DE1@austin.rr.com обсуждение исходный текст |
Ответ на | [HACKERS] Transaction abortions & recovery handling (Ed Loehr <eloehr@austin.rr.com>) |
Ответы |
Re: [HACKERS] Transaction abortions & recovery handling
|
Список | pgsql-hackers |
Tom Lane wrote: > > Ed Loehr <eloehr@austin.rr.com> writes: > > Any suggestions on how I might handle this? > > Er ... run 7.0beta ? Probably a cleaner answer than hacking up your > app to implement an incomplete workaround for that 6.5 bug. > > Year before last, I moved my company's production applications onto > a pre-alpha 6.4 snapshot, because we were getting killed by a bad bug > in 6.3.*. It made me pretty nervous, but guess what: we didn't have > any problems. I was sure that would be someone's first response. I'd like to express my perspective and see if you still stick with your advice... [flame suit on] My system is live. As such, I really don't want to trade this known problem for (unknown) additional adjustments to 7.0beta right now (pg_dump & views, not null unique, etc), also due to my own time constraints. Based on recent threads on this list, I have the impression that 7.0beta is not quite ready for production. The recent flaming of one fellow for, among other things, using it in his near-production system reinforced my impression. Before I get derided and flamed, let me admit I haven't tracked all these issues to their conclusion, nor am I watching cvs for fixes. [flame suit off] Additionally, I already have the app code in place to catch the error & vacuum, and I think it has even worked in the past, though something has apparently changed on my end to make that cease. Having said all that, do you still advise 7.0beta for production? Or might there be a simple workaround to my original question? OK, flame away... Regards, Ed Loehr
В списке pgsql-hackers по дате отправления: