| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-06-24 19:31:29 |
| Message-ID: | CAH2-WzkS9FGey1XZLP9cwvz-t2iqdiwaqh5vejtm3PVVGpLOXw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 24, 2024 at 3:23 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> I had always thought it was because the vacuuming backend's
> GlobalVisState will get updated periodically throughout vacuum and so,
> assuming the oldest running transaction changes, our horizon for
> vacuum would change.
I believe that it's more of an aspirational thing at this point. That
it is currently aspirational (it happens to some extent but isn't ever
particularly useful) shouldn't change the analysis about how to fix
this bug.
> One of those is at the
> end of index vacuuming, but that can only affect the pruning horizon
> if we have to do multiple rounds of index vacuuming. Is that really
> the case we are thinking of when we say we want the pruning horizon to
> move forward during vacuum?
No, that's definitely not what we were thinking of. It's just an
accident that it's almost the only thing that'll do that.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2024-06-24 19:35:57 | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |
| Previous Message | Stan Hu | 2024-06-24 19:25:05 | Re: PostgreSQL does not compile on macOS SDK 15.0 |