From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Bogus "Non-functional update" notices |
Date: | 1998-07-28 14:14:06 |
Message-ID: | 4350.901635246@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vadim Mikheev <vadim(at)krs(dot)ru> writes:
> In UPDATE backend inserts index tuple for new version of heap tuple
> and adjusts all index scans affected by this insertion.
> Something is wrong in nbtscan.c:_bt_adjscans()...
Could be; maybe there's one boundary case that fails to advance the
index scan? I hope there's someone who's looked at nbtree recently
who can take the time to debug this.
Another thing that struck me while looking at the update code is that
an update deletes the old tuple value, then inserts the new value,
but it doesn't bother to delete any old index entries pointing at the
old tuple. ISTM that after a while, there are going to be a lot of old
index entries pointing at dead tuples ... or, perhaps, at *some other*
live tuple, if the space the dead tuple occupied has been reused for
something else. This certainly seems to present a risk of returning
the wrong tuple. I looked through the code to find out how such an
error is prevented, and didn't find anything. But maybe I just don't
know where to look.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1998-07-28 14:42:26 | Re: [HACKERS] 6.1 pg_dump core dump |
Previous Message | Peter T Mount | 1998-07-28 10:06:01 | Re: [HACKERS] current snapshot |