Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
John Naylor <johncnaylorls@gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: 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>,
Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>
Date: 2024-08-10T09:01:18Z
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 →
-
Test that vacuum removes tuples older than OldestXmin
- 2c0bc4765741 17.6 landed
- 303ba0573ce6 18.0 landed
- 80c34692e8e6 17.0 landed
- aa607980aee0 18.0 landed
-
Lower minimum maintenance_work_mem to 64kB
- 2eda3df9ad53 17.0 landed
- bbf668d66fbf 18.0 landed
-
Add accidentally omitted test to meson build file
- 9d198f4d3e3b 16.4 landed
-
Use DELETE instead of UPDATE to speed up vacuum test
- 924a08b76f5d 14.13 landed
- 9744fe24118b 15.8 landed
- 571e0ee40ebd 16.4 landed
-
Revert "Test that vacuum removes tuples older than OldestXmin"
- efcbb76efe40 18.0 landed
- 1a3e90948b50 17.0 landed
-
Ensure vacuum removes all visibly dead tuples older than OldestXmin
- fd4f12df5e46 17.0 landed
- 83c39a1f7f3f 18.0 landed
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.