Re: BUG #14150: Attempted to delete invisible tuple
От | Andres Freund |
---|---|
Тема | Re: BUG #14150: Attempted to delete invisible tuple |
Дата | |
Msg-id | 20160728004737.5x5pakboh24234j6@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #14150: Attempted to delete invisible tuple (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #14150: Attempted to delete invisible tuple
|
Список | pgsql-bugs |
On 2016-07-27 16:53:47 -0700, Andres Freund wrote: > 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. Oh, and this desperately needs a minimal test. Shouldn't be hard to do with isolationtester.
В списке pgsql-bugs по дате отправления: