Re: [HACKERS] Bogus "Non-functional update" notices
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Bogus "Non-functional update" notices |
Дата | |
Msg-id | 35BE77D5.3023F8B1@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Bogus "Non-functional update" notices (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Bogus "Non-functional update" notices
|
Список | pgsql-hackers |
Tom Lane wrote: > > 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. I'll try to look there... > 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. Vacuum deletes index tuples before deleting heap ones... Vadim
В списке pgsql-hackers по дате отправления: