DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
	b=AXyQtqJ/mVjSwfNXxbFlr8O1lFxoNG/j6ECmOwNCKBMt92/loyiGo0x4fxvn6sYnB6jr3gGnW5NtOxkI4YhtnF11KjDm3aYATNU7TZCuYnEuaSbpvWjFgnW9Dxds2WxB/3t2YcDxq1Fg2VMKlmLkp5H/L33KOFTkyx4rh1wfvPg=
Message-ID: <46FD5695.6000302@enterprisedb.com>
Date: Fri, 28 Sep 2007 20:31:33 +0100
From: Heikki Linnakangas <heikki@enterprisedb.com>
User-Agent: Icedove 1.5.0.12 (X11/20070730)
MIME-Version: 1.0
To: Peter Schuller <peter.schuller@infidyne.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Non-blocking vacuum full
References: <20070928180649.GA6579@hyperion.scode.org>
In-Reply-To: <20070928180649.GA6579@hyperion.scode.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Schuller wrote:
> I have only looked very very briefly at the PG code so I don't know
> how far fetched it is, but my thought was that it should be possible
> to have a slow background process (similar to normal non-full vacuums
> nows) that would, instead of registering dead tuples in the FSM, move
> live tuples around.

What you've described is actually very close to VACUUM FULL. VACUUM FULL
needs to take an exclusive lock to lock out concurrent scanners that
might miss or see a tuple twice, when a live tuple is moved. That's the
fundamental problem you need to solve.

I think it's doable, if you take a copy of the tuple, and set the ctid
pointer on the old one like an UPDATE, and wait until the old tuple is
no longer visible to anyone before removing it. It does require some
changes to tuple visibility code. For example, a transaction running in
serializable mode shouldn't throw a serialization error when it tries to
update an old, moved row version, but follow the ctid pointer instead.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com