Thread
-
Re: [HACKERS] Bogus "Non-functional update" notices
Tom Lane <tgl@sss.pgh.pa.us> — 1998-07-29T14:40:59Z
Vadim Mikheev <vadim@krs.ru> writes: > Tom Lane wrote: >> 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. > Vacuum deletes index tuples before deleting heap ones... Right, but until you've done a vacuum, what's stopping the code from returning wrong tuples? I assume this stuff actually works, I just couldn't see where the dead index entries get rejected. regards, tom lane
-
Re: [HACKERS] Bogus "Non-functional update" notices
David Gould <dg@illustra.com> — 1998-07-29T16:05:54Z
> Vadim Mikheev <vadim@krs.ru> writes: > > Tom Lane wrote: > >> 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. > > > Vacuum deletes index tuples before deleting heap ones... > > Right, but until you've done a vacuum, what's stopping the code from > returning wrong tuples? I assume this stuff actually works, I just > couldn't see where the dead index entries get rejected. > > regards, tom lane > Without checking the code, I suspect that dead rows are visible though the index (they had to be to make time travel work), but do not match the time qual so are not "seen". -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 - If simplicity worked, the world would be overrun with insects. -
-
Re: [HACKERS] Bogus "Non-functional update" notices
Vadim Mikheev <vadim@krs.ru> — 1998-07-30T01:16:57Z
David Gould wrote: > > > > > > Vacuum deletes index tuples before deleting heap ones... > > > > Right, but until you've done a vacuum, what's stopping the code from > > returning wrong tuples? I assume this stuff actually works, I just > > couldn't see where the dead index entries get rejected. > > > > Without checking the code, I suspect that dead rows are visible though the > index (they had to be to make time travel work), but do not match the time > qual so are not "seen". Yes. Backend sees that xmax of heap tuple is committed and don't return tuple... BTW, I've fixed SUBJ. Scan adjustment didn't work when index page was splitted. I get rid of ON INSERT adjustment at all: now backend uses heap tid of current index tuple to restore current scan position before searching for the next index tuple. (This will also allow us unlock index page after we got index tuple and work in heap and so index readers will not block writers ... when LLL will be implemented -:). The bug was more serious than "non-functional update" when backend read index tuples twice: in some cases scan didn't return good tuples at all! drop table bt; create table bt (x int); copy bt from '/var/home/postgres/My/Btree/ADJ/UNIQ'; -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- 1000 records with x in [1,1000] -- create index bti on bt (x); update bt set x = x where x <= 200; update bt set x = x where x > 200 and x <= 210; -- -- ONLY 4 tuples will be updated by last update! -- I'll prepare patch for 6.3... Vadim