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 по дате отправления:

Предыдущее
От: "Dr. Michael Meskes"
Дата:
Сообщение: Re: [HACKERS] Q about read committed in Oracle...
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Coping with backend crash in libpq