Re: Toast issues with OldestXmin going backwards

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Toast issues with OldestXmin going backwards
Дата
Msg-id CA+TgmoaG1Zjg1KLUX1WfxktNEu4Q=Zxjman=X5fTJ1ErTDVxvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Toast issues with OldestXmin going backwards  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: Toast issues with OldestXmin going backwards  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Fri, Apr 27, 2018 at 11:35 AM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Robert" == Robert Haas <robertmhaas@gmail.com> writes:
>  Robert> One idea that occurred to me is to somehow record -- I guess in
>  Robert> pg_class using non-transactional updates -- the last cutoff XID
>  Robert> used to vacuum any given table. Then we could just make a rule
>  Robert> that you can't vacuum the TOAST table with an XID that's newer
>  Robert> than the last one used for the main table. That would preserve
>  Robert> the property that you can vacuum the tables separately while
>  Robert> avoiding dangling pointers. But that's obviously not
>  Robert> back-patchable,
>
> The suggestion made previously (in a historical thread) was to use an
> entry in the reloptions field for this, at least in back branches. It
> would be necessary for vacuum to add the entry initially in a normal
> transactional update, after which it could be updated inplace.

Yeah, I suppose.  Sounds pretty rickety to me, though.  Maybe I'm just
a pessimist.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: obsoleting plpython2u and defaulting plpythonu to plpython3u
Следующее
От: Kefan Yang
Дата:
Сообщение: RE: GSoC 2018: Sorting Algorithm and Benchmarking