Re: Order of operations in lazy_vacuum_rel

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Order of operations in lazy_vacuum_rel
Дата
Msg-id 20100209014648.GC4113@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Order of operations in lazy_vacuum_rel  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Order of operations in lazy_vacuum_rel  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Order of operations in lazy_vacuum_rel
Следующее
От: Andrew McNamara
Дата:
Сообщение: Re: Confusion over Python drivers