| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Teodor Sigaev <teodor(at)stack(dot)net> |
| Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Ivan Panchenko <ivan(at)xray(dot)sai(dot)msu(dot)ru> |
| Subject: | Re: strange update problem with 7.2.1 |
| Date: | 2002-05-28 13:33:07 |
| Message-ID: | 2579.1022592787@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Teodor Sigaev <teodor(at)stack(dot)net> writes:
>> Hmm, is this patch really correct? Removing the gistadjscans() call
>> from gistSplit seems wrong to me --- won't that miss reporting splits
>> on leaf pages? Or does this not matter for some reason?
> gistadjscans() is moving to gistlayerinsert. gistadjscans() must be
> called for parent of splitted page, but gistSplit doesn't know parent
> of current page and gistlayerinsert return status of its action:
> inserted and (may be) splitted. So we can call
> gistadjscans(GIST_SPLIT) in gistlayerinsert when it's need.
But gistSplit is recursive. Is there no need to worry about the
additional splits it might do internally?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kovacs Zoltan | 2002-05-28 13:53:34 | cache lookup failed: hack pg_* tables? |
| Previous Message | Joel Burton | 2002-05-28 13:09:04 | Re: wierd AND condition evaluation for plpgsql |