Re: Order of operations in lazy_vacuum_rel - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Order of operations in lazy_vacuum_rel
Date
Msg-id 20100209014648.GC4113@alvh.no-ip.org
Whole thread Raw
In response to Re: Order of operations in lazy_vacuum_rel  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Order of operations in lazy_vacuum_rel
List pgsql-hackers
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.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Order of operations in lazy_vacuum_rel
Next
From: Andrew McNamara
Date:
Subject: Re: Confusion over Python drivers