Tom Lane wrote:
> Ed Loehr <eloehr(at)austin(dot)rr(dot)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...
In response to
pgsql-hackers by date
|Next:||From: Ross J. Reedstrom||Date: 2000-03-09 00:22:20|
|Subject: Re: [HACKERS] DROP TABLE inside a transaction block|
|Previous:||From: Tom Lane||Date: 2000-03-08 23:51:37|
|Subject: Re: [HACKERS] alter_table.sql |