Re: [HACKERS] RE: Getting rid of setheapoverride (was Re: [COMMITTERS] heap.c)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] RE: Getting rid of setheapoverride (was Re: [COMMITTERS] heap.c) |
Дата | |
Msg-id | 200001170613.BAA13224@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] RE: Getting rid of setheapoverride (was Re: [COMMITTERS] heap.c) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] RE: Getting rid of setheapoverride (was Re: [COMMITTERS] heap.c)
|
Список | pgsql-hackers |
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > Oh,I was just looking at heapoverride stuff quite accidentally. > > Yes, this call is ugly and should be replaced by CommandCounterIncrement(). > > OK, I'm running a build now with setheapoverride calls removed. > Will see what happens. > > About half of the setheapoverride calls surrounded heap_update() > (formerly called heap_replace()) calls. AFAICS there is no need > for these calls unless heap_update itself needs them --- but there > are many calls to heap_update that do not have setheapoverride. > Perhaps heap_replace once needed setheapoverride but no longer does? > > I am going to try just removing these calls without adding a > CommandCounterIncrement to replace them. If anyone knows that > this is a bad idea, let me know! Go for it. The setheapoverride name was so confusing, people just probably left it in, not knowing what it did. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: