Re: BUG #14150: Attempted to delete invisible tuple
От | Andres Freund |
---|---|
Тема | Re: BUG #14150: Attempted to delete invisible tuple |
Дата | |
Msg-id | 20160727235347.odtjfrsrjdrlolfv@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #14150: Attempted to delete invisible tuple (Oskari Saarenmaa <os@aiven.io>) |
Ответы |
Re: BUG #14150: Attempted to delete invisible tuple
Re: BUG #14150: Attempted to delete invisible tuple |
Список | pgsql-bugs |
On 2016-07-07 22:43:59 +0300, Oskari Saarenmaa wrote: > Something like the attached patch? It > still modifies the toast_delete API, but > we could also implement a new > speculative-tuple-aware version of it if > that's a concern. Maybe I'm missing something, but toasted columns aren't actually marked as speculative right now, no? Cf. HeapTuple toast_insert_or_update(Relation rel, HeapTuple newtup, HeapTuple oldtup, int options) .. /* * Ignore the INSERT_SPECULATIVE option. Speculative insertions/super * deletions just normally insert/delete the toast values. It seems * easiest to deal with that here, instead on, potentially, multiple * callers. */ options &= ~HEAP_INSERT_SPECULATIVE; so going through heap_abort_speculative()/heap_delete_speculative() doesn't look right to me. We could change thing so toasted rows also get inserted speculatively - but I don't see much of a point. > +void > +heap_delete_speculative(Relation relation, ItemPointer tid, bool is_toast) > +{ If we go this way, it seems easier to get is_toast from IsToastRelation(relation), rather than hand it through painstakingly. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: