Horton

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

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: John Naylor <johncnaylorls@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Heikki Linnakangas <hlinnaka@iki.fi>, Pg Hackers <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>
Date: 2024-08-10T21:47:57Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Test that vacuum removes tuples older than OldestXmin

  2. Lower minimum maintenance_work_mem to 64kB

  3. Add accidentally omitted test to meson build file

  4. Use DELETE instead of UPDATE to speed up vacuum test

  5. Revert "Test that vacuum removes tuples older than OldestXmin"

  6. Ensure vacuum removes all visibly dead tuples older than OldestXmin

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