| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Melanie Plageman <melanieplageman(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 17:05:10 |
| Message-ID: | CA+Tgmob4m4TjFCqKFvdR9=Y71fGoH_C-nfPgni6Trt8t3AKOLA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 24, 2024 at 12:43 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> The problem here is that OldestXmin is supposed to be more
> conservative than vistest, which it almost always is, except in this
> one edge case. I don't think that plugging that hole changes the basic
> fact that there is one source of truth about what *needs* to be
> pruned. There is such a source of truth: OldestXmin.
Well, another approach could be to make it so that OldestXmin actually
is always more conservative than vistest rather than almost always.
I agree with you that letting the pruning horizon move forward during
vacuum is desirable. I'm just wondering if having the vacuum code need
to know a second horizon is really the best way to address that.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-06-24 17:29:18 | Re: POC, WIP: OR-clause support for indexes |
| Previous Message | Peter Geoghegan | 2024-06-24 16:42:55 | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |