Re: Toast issues with OldestXmin going backwards

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Toast issues with OldestXmin going backwards
Дата
Msg-id 87o9iabtkt.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Toast issues with OldestXmin going backwards  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

 Andrew> Since the tuple was vacuumable at that point, it will never
 Andrew> again become visible in any snapshot, so the only code that
 Andrew> should ever access its toast values is vacuum full/cluster,

and, unfortunately, CREATE INDEX (non-concurrently), including the index
build done by vacfull/cluster itself, which rather messes things up
because the toasted column might be a parameter to a functional index, or it
might itself be an indexed column (within a narrow size range for btree,
or more generally for other index types); this means the index AM or the
indexed function may try and actually detoast and inspect the value.

So right now it's possible (I think) in the worst case to crash the
server if you can set up exactly the right circumstances (re-use of a
prematurely vacuumed toast oid after wraparound, with the new value
matching the old value's raw length but not its compression state).

(My changes so far don't address this case and don't make it either more
or less likely)

-- 
Andrew (irc:RhodiumToad)


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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning
Следующее
От: Amit Langote
Дата:
Сообщение: using expression syntax for partition bounds (was: Re: Booleanpartitions syntax)