Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

Поиск
Список
Период
Сортировка
От John Naylor
Тема Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Дата
Msg-id CANWCAZYE5tHJPiH1uwuFtteAnDbi-ZDYBSg6=Yp9RCJPY7LJRw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin  (John Naylor <johncnaylorls@gmail.com>)
Ответы Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Список pgsql-hackers
On Tue, Aug 6, 2024 at 9:58 PM John Naylor <johncnaylorls@gmail.com> wrote:
>
> It also turns out that to support 64kB memory settings, we actually
> wouldn't need to change radix tree to lazily create memory contexts --
> at least currently, SlabCreate doesn't allocate a keeper block, so a
> newly created slab context reports 0 for "mem_allocated". So I'm
> inclined to go ahead change the minimum m_w_m on v17 and master to
> 64kB. It's the quickest and (I think) most future-proof way to make
> this test work. Any objections?

This is done. I also changed autovacuum_work_mem just for the sake of
consistency. I did some quick math and found that there shouldn't be a
difference between 32- and 64-bit platforms for when they exceed 64kB
in the tid store. That's because exceeding the limit is caused by
allocating the first block of one of the slab contexts. That
independence may not be stable, so I'm thinking of hard-coding the
block sizes in master only, but I've left that for another time.



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