From: | Mike Mascari <mascarm(at)mascari(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | mlw <markw(at)mohawksoft(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Concerns about this release |
Date: | 2001-12-18 19:13:15 |
Message-ID: | 3C1F954B.5670FC92@mascari.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> mlw <markw(at)mohawksoft(dot)com> writes:
> > I kind of second your opinion here. I also have my doubts that the
> > default is not as well tested as the option.
>
> By that logic, we could never make any new releases, or at least never
> add any new code. "New code isn't as well tested as old code" is an
> unhelpful observation.
>
> FWIW, I trust lazy VACUUM a lot *more* than I trust the old VACUUM code.
> Read the tuple-chain-moving logic in vacuum.c sometime, and then tell me
> how confident you feel in it. (My gut tells me that that logic is
> responsible for the recent reports of duplicate tuples in 7.1.*, though
> I can't yet back this up with any evidence.)
For all the various bugs which have been in PG over the years, the
recent crop of "duplicate tuples" is the absolute scariest. Can a
release really be made without knowing precisely the cause of those
corruptions? The various theories offered by the posters (SMP
machine, CREATE INDEX in pl/pgsql functions, etc.) aren't comforting
either. To me, all other feature enhancements pale in comparison to
pinning down this bug.
Just my opinion,
Mike Mascari
mascarm(at)mascari(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-18 19:20:00 | Re: problems with table corruption continued |
Previous Message | Mikheev, Vadim | 2001-12-18 19:11:55 | Re: Deadlock condition in current sources |