| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |
| Date: | 2022-03-31 17:16:59 |
| Message-ID: | CAH2-Wz=1gM=-42XWq3BU=101g6655wvLLqyqCdQw6iY6zoOsjg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 31, 2022 at 10:11 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't think we should weaken defenses against xids from before relfrozenxid
> in vacuum / amcheck / .... If anything we should strengthen them.
>
> Isn't it also just plainly required for correctness? We'd not necessarily
> trigger a vacuum in time to remove the xid before approaching wraparound if we
> put in an xid before relfrozenxid? That happening in prune_xid is obviously
> les bad than on actual data, but still.
Yeah, you're right. Ambiguity about stuff like this should be avoided
on general principle.
> ISTM we should just use our own xid. Yes, it might delay cleanup a bit
> longer. But unless there's already crud on the page (with prune_xid already
> set, the abort of the speculative insertion isn't likely to make the
> difference?
Speculative insertion abort is pretty rare in the real world, I bet.
The speculative insertion precheck is very likely to work almost
always with real workloads.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2022-03-31 17:35:55 | Re: unlogged sequences |
| Previous Message | Peter Geoghegan | 2022-03-31 17:12:49 | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |