Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
От | Andres Freund |
---|---|
Тема | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |
Дата | |
Msg-id | uvug7q7cu2cbeojf3v53wnona2qlm67x73kwigpiw4sra63ke3@kqlgmez7zzla обсуждение исходный текст |
Ответ на | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin (John Naylor <johncnaylorls@gmail.com>) |
Список | pgsql-hackers |
On 2024-08-10 16:01:18 +0700, John Naylor wrote: > 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. Thanks a lot! Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: