Re: Nasty bug in heap_page_prune
От | Tom Lane |
---|---|
Тема | Re: Nasty bug in heap_page_prune |
Дата | |
Msg-id | 17962.1205423537@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Nasty bug in heap_page_prune ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
Ответы |
Re: Nasty bug in heap_page_prune
|
Список | pgsql-hackers |
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes: > I wonder if we can have a separate list of non-transaction events in > InvalidationListHeader and broadcast those events irrespective of > transaction commit or abort. Yeah, I started with that same idea. But AFAICS there is no percentage in postponing the broadcast until commit/abort; we may as well push the messages out immediately. The reason inval postpones transactional messages until commit/abort is that that's when the invalidation actually "takes effect" (or not) from the point of view of other transactions; telling them to flush their caches earlier would be useless. For these nontransactional invalidations the inval is effective immediately, and other sessions can reload their caches as soon as we release buffer lock. (Well, except that VACUUM FULL is holding ex-lock on the whole table...) Anyway, point is that that seems to be extra complication that doesn't buy anything, and if anything puts the behavior further away from what it should ideally be. regards, tom lane
В списке pgsql-hackers по дате отправления: