From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Nasty bug in heap_page_prune |
Date: | 2008-03-13 15:52:17 |
Message-ID: | 17962.1205423537@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-03-13 15:56:33 | Re: Reducing Transaction Start/End Contention |
Previous Message | Tom Lane | 2008-03-13 15:43:22 | Re: Encoding problems with migration from 8.0.14 to 8.3.0 on Windows |