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

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Date: 2024-08-10 09:01:18
Message-ID: CANWCAZYE5tHJPiH1uwuFtteAnDbi-ZDYBSg6=Yp9RCJPY7LJRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 6, 2024 at 9:58 PM John Naylor <johncnaylorls(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Imran Zaheer 2024-08-10 09:21:43 Re: SQL Property Graph Queries (SQL/PGQ)
Previous Message Kirill Reshke 2024-08-10 07:22:00 Re: EphemeralNamedRelation and materialized view