Date: Mon, 8 Feb 2010 22:46:48 -0300
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki@enterprisedb.com>, pgsql-hackers@postgreSQL.org
Subject: Re: Order of operations in lazy_vacuum_rel
Message-ID: <20100209014648.GC4113@alvh.no-ip.org>
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>
	<2770.1265675743@sss.pgh.pa.us>
	<20100209011808.GA4113@alvh.no-ip.org>
	<4483.1265679166@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4483.1265679166@sss.pgh.pa.us>
User-Agent: Mutt/1.5.20 (2009-06-14)

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Tom Lane wrote:
> >> Actually, after thinking about this some more, I realize that this code
> >> has got a significantly bigger problem than just whether it will respond
> >> to CANCEL promptly.
> 
> > Err, that problem was exactly why I added the interrupt holdoff in
> > there, so if you've got a better/more invasive solution, it's very
> > welcome.
> 
> Well, that's a pretty incomplete solution :-(.

Yeah, we were well aware of that :-)  It solved our problem (which was
related to interrupts from autovac)

> Maybe we should do
> something about this.  There wasn't any obvious solution before,
> but now that we have the nontransactional smgr-level sinval messages
> being sent on drops and truncates, it seems like tying rd_targblock
> clearing to those would fix the problem.

Hmm, sounds good, though I confess not having heard about
nontransactional sinval messages before.

> The easiest way to do that
> would involve moving rd_targblock down to the SMgrRelation struct.
> Probably rd_fsm_nblocks and rd_vm_nblocks too.  Comments?

Can't say it doesn't look like a modularity violation from here --
insertion target block doesn't really belong into smgr, does it?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.