Message-ID: <4B706D81.7010600@enterprisedb.com>
Date: Mon, 08 Feb 2010 22:01:05 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: Alvaro Herrera <alvherre@commandprompt.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: Order of operations in lazy_vacuum_rel
References: <13481.1265650179@sss.pgh.pa.us>
	<20100208173855.GN4113@alvh.no-ip.org>
	<13824.1265651227@sss.pgh.pa.us>
	<20100208191917.GO4113@alvh.no-ip.org>
In-Reply-To: <20100208191917.GO4113@alvh.no-ip.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Alvaro Herrera wrote:
> Tom Lane wrote:
>> The point would be to not disable interrupts till after doing the FSM
>> vacuuming.  Ignoring CANCEL for longer than we must is bad.
> 
> Oh, I see.  I guess the answer is that it depends on what happens if you
> interrupt after vacuuming the FSM.  I have no idea what that is supposed
> to accomplish so I'm of no help here.  FreeSpaceMapVacuum says it's
> about fixing inconsistencies in the FSM, so I'm guessing that it's not
> critical.

Yeah, interrupting FreeSpaceMapVacuum (or right after it) is harmless.

> FWIW I notice that RelationTruncate contains an outdated comment at the
> top about the 'fsm' function argument which is nowadays no longer an
> argument.

Thanks, fixed.

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