Re: (one more time) Patches with vacuum fixes available .

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: (one more time) Patches with vacuum fixes available .
Date: 2001-01-24 18:50:10
Message-ID: 3A6F23E2.36B9F3AF@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
>
> Did we decide against LAZY? Seems we have a number of people concerned
> about vacuum downtime, and I can see this as a win for them. If they
> don't specify LAZY, the code is not run.

I see a number of possibilities:
1.) A tested 'feature patch' available for separate download;
2.) A configure switch '--enable-lazy-vacuum' perhaps;
3.) The (marginally if at all documented) LAZY parameter, with the code
sitting there dormant until the parameter is passed. Those who need it
probably read this list anyway.

Are we anywhere near comfortable that the code to support LAZY doesn't
impact standard VACUUM in any way? That for me is the acid test -- if
VACUUM proper gets a bug due to the addition, that would be _bad_. But,
if someone either applied the feature patch or enabled the configure
switch, well, then that's their choice, and their problem.

Then those who don't need it can still have reasonable confidence in the
solidity of the VACUUM code. The fact that LAZY will get really lazy
and go away at 7.2 is a factor, as well. But the fact that 7.2, which
will obviate all this (hopefully), is several months at the very least
down the road makes it desireable NOW to have the LAZY behavior.

I for one don't _need_ the LAZY behavior -- my VACUUMs take seconds, not
hours.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nick Gorham 2001-01-24 18:53:42 Re: Re: unixODBC again :-(
Previous Message Bruce Momjian 2001-01-24 18:47:49 Re: [INTERFACES] ODBC gives pq_recvbuf: unexpected EOF on client connection