Re: Nasty bug in heap_page_prune
От | Hannu Krosing |
---|---|
Тема | Re: Nasty bug in heap_page_prune |
Дата | |
Msg-id | 1204884765.6568.1.camel@huvostro обсуждение исходный текст |
Ответ на | Nasty bug in heap_page_prune (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Nasty bug in heap_page_prune
|
Список | pgsql-hackers |
On Wed, 2008-03-05 at 20:23 -0500, Tom Lane wrote: > Not sure about a clean solution to this. I don't really want to > bastardize inval.c by making it deal with nontransactional semantics, > but there may be no other way. Is this something that happens only with concurrent VACUUM FULLs ? If so, than can't we just disallow doing them concurrently ? VACUUM FULL is something you don't want on a high-load database anyway > Or we could forget about letting VACUUM FULL collapse out LP_REDIRECT > pointers, at least in system catalogs. That might be the best answer > for 8.3 in any case; I am not seeing a real fix that I'd care to risk > back-patching. (Note that this is not exactly trivial in itself, since > then vacuum.c would need at least some minimal ability to deal with > LP_REDIRECT entries.) > > regards, tom lane Hannu Krosing
В списке pgsql-hackers по дате отправления: