| 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-07-28 03:20:02 |
| Message-ID: | CANWCAZYeHnBiC32cFTmr-WKmoJ2_qCDQt4yNgL17VvpR+SNqxA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Saturday, July 27, 2024, Melanie Plageman <melanieplageman(at)gmail(dot)com>
wrote:
>
>
> Yes, the only thing that is important is having two rounds of index
> vacuuming and having one tuple with a value matching my cursor
> condition before the first index vacuum and one after. What do you
> mean update only the last few tuples though?
>
I meant we could update tuples with the highest offsets on each page. That
would then lead to longer arrays of bitmaps to store offsets during vacuum.
Lowering the minimum memory setting is easier to code and reason about,
however.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2024-07-28 03:42:36 | Re: Fix overflow in pg_size_pretty |
| Previous Message | Thomas Munro | 2024-07-28 01:19:38 | Re: why is pg_upgrade's regression run so slow? |