Getting rid of setheapoverride (was Re: [COMMITTERS] heap.c)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Getting rid of setheapoverride (was Re: [COMMITTERS] heap.c)
Date: 2000-01-17 03:46:34
Message-ID: 7604.948080794@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>>> Tom, any chance we can change the name of setheapoverried to something
>>>> that makes sense?
>>
>> Actually, I thought the plan was to eliminate it entirely in favor of
>> using CommandCounterIncrement when we need to make tuples visible.
>> There was a thread about that back in September, but I guess no one's
>> gotten around to actually doing it.

> I remember in the old days being totally confused about its purpose.
> That was my motivation to change it. Can I do something to help fix
> this?

Actually, according to my notes I had put off doing anything with this
because Hiroshi pointed out that CommandCounterIncrement had a shared-
cache-invalidation problem (it sent SI messages for changes that we
couldn't yet be sure would get committed).

Hiroshi's message last Monday stated that he'd fixed that problem,
so maybe now it's safe to start using CommandCounterIncrement more
heavily. Hiroshi, what do you think --- do you trust
CommandCounterIncrement now?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-01-17 04:20:37 RE: Getting rid of setheapoverride (was Re: [COMMITTERS] heap.c)
Previous Message Tom Lane 2000-01-17 03:23:03 Re: Inhterit fix