| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Ivan Panchenko <ivan(at)xray(dot)sai(dot)msu(dot)ru>, Teodor Sigaev <teodor(at)stack(dot)net> |
| Subject: | Re: strange update problem with 7.2.1 |
| Date: | 2002-05-25 17:28:29 |
| Message-ID: | 27654.1022347709@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> On Sat, 25 May 2002, Tom Lane wrote:
>> I get the same in current sources (in fact the number of rows updated
>> varies from try to try). Are you sure it's not a problem with the
>> gist index mechanism?
> We'll look once more, but code for select and update should be the same.
Yeah, but the update case is inserting more entries into the index.
I'm wondering if that causes the index scan's state to get corrupted
so that it misses scanning some entries. btree has a carefully designed
algorithm to cope with this, but I have no idea how gist manages it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-05-25 18:21:52 | Think I see a btree vacuuming bug |
| Previous Message | Tom Lane | 2002-05-25 17:07:13 | Getting rid of ReferentialIntegritySnapshotOverride |