Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) |
| Дата | |
| Msg-id | 2491.1462889347@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: HeapTupleSatisfiesToast() busted? (was atomic
pin/unpin causing errors)
|
| Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes:
> Is anybody ready with a good defense for SatisfiesToast not doing any
> actual liveliness checks?
As long as we do not update toast values after creation, there is no
need; the liveness check on the parent tuple is what's important.
Adding a liveness check on the toast item would merely create new
failure modes with no corresponding benefit. Imagine deciding
that field 3 of a regular tuple was somehow dead even though the
rest of the tuple is live --- how can that be good?
I concur with Robert that what this looks like is failure to ensure
that toast OIDs are unique, which is an entirely different problem.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера