On Thu, Mar 13, 2008 at 9:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> 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.
Seems like a good plan to me.
Thanks,
Pavan
-
"Pavan Deolasee" <[EMAIL PROTECTED]> 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 postponi
On Thu, Mar 13, 2008 at 10:23 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> But we could push them out earlier, ie,
> before making the actual page changes in heap_page_prune. This seems
> safe since an unnecessary invalidation notice cannot break anything,
> at worst it causes useless work.
>
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On Thu, Mar 6, 2008 at 6:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> While working on the previously discussed refactoring of
>> heap_page_prune, I came to the realization that its use of
>> CacheInvalidateHeapTuple is not just a PANIC risk but simpl
Tom Lane escribió:
> 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.
FWIW IIRC we hit precisely this problem while trying to do the
pg_class_nt stuff awhile ago, so if it's ov
On Fri, Mar 7, 2008 at 3:42 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>
> Is this something that happens only with concurrent VACUUM FULLs ?
>
No, its about VACUUM FULL on a system catalog which fails for some reason.
The VACUUM FULL may have changed CTID of a tuple because of line
pointer re
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
On Thu, Mar 6, 2008 at 6:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> While working on the previously discussed refactoring of
> heap_page_prune, I came to the realization that its use of
> CacheInvalidateHeapTuple is not just a PANIC risk but simply wrong :-(
> The semantics aren't right: inval
