| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com> |
| Subject: | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |
| Date: | 2024-06-25 23:33:35 |
| Message-ID: | CA+TgmoYWmSwUVG+TZ6jfjX3UqjTGJzbcFyW0Qjm-2hGKdMEwcA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 25, 2024 at 4:41 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I doubt that's doable in the back branches. And even on HEAD, I don't think
> it's a particularly attractive option - there's just a global vistest for each
> of the types of objects with a specific horizon (they need to be updated
> occasionally, e.g. when taking snapshots). So there's not really a spot to put
> an associated OldestXmin. We could put it there and remove it at the end of
> vacuum / in an exception handler, but that seems substantially worse.
Oh, right: I forgot that the visibility test objects were just
pointers to global variables.
Well, I don't know. I guess that doesn't leave any real options but to
fix it as Melanie proposed. But I still don't like it very much. I
feel like having to test against two different thresholds in the
pruning code is surely a sign that we're doing something wrong.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2024-06-25 23:54:09 | CI, macports, darwin version problems |
| Previous Message | Alena Rybakina | 2024-06-25 23:13:53 | Re: POC, WIP: OR-clause support for indexes |