Re: Concerns about this release

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

In response to

Responses

Browse pgsql-hackers by date

  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