Re: [HACKERS] Bogus "Non-functional update" notices - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Bogus "Non-functional update" notices
Date
Msg-id 4350.901635246@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Bogus "Non-functional update" notices  (Vadim Mikheev <vadim@krs.ru>)
List pgsql-hackers
Vadim Mikheev <vadim@krs.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

pgsql-hackers by date:

Previous
From: Peter T Mount
Date:
Subject: Re: [HACKERS] current snapshot
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] 6.1 pg_dump core dump