Re: Bugs in TOAST handling, OID assignment and redo recovery

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Bugs in TOAST handling, OID assignment and redo recovery
Дата
Msg-id CABOikdNoU8=5RjckqwnBFhjrgF4DU0SWw7sPry5Qfo4q7N0-4Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bugs in TOAST handling, OID assignment and redo recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bugs in TOAST handling, OID assignment and redo recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Дерево обсуждения


On Wed, Apr 11, 2018 at 8:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> Or may be we simply err on the side of caution and scan the toast table
> with SnapshotAny while looking for a duplicate? That might prevent us from
> reusing an OID for a known-dead tuple, but should save us a second index
> scan and still work.

+1.  We really don't want to expend two indexscans on this.


Ok. I propose attached patches, more polished this time. I also changed toastrel_valueid_exists() to use SnapshotAny, but I don't have any proofs to claim that's a needed change. But it seems harmless and given the number of toast related, hard to chase bugs we have seen over the years, may it's worth making it full proof too.

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: lazy detoasting
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.