| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: do only critical work during single-user vacuum? |
| Date: | 2022-02-16 20:21:31 |
| Message-ID: | CAH2-Wz=2fE5YCYqOcV_g1JEDdPoVu2Q+wHNCiMsGWTdMqQj0mg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 16, 2022 at 12:11 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> No, I think it's PostgreSQL 13, because before the vacuum failsafe
> thing you could end up truncating enough tables during vacuum
> operations to actually wrap around.
Why wouldn't the xidStopLimit thing prevent actual incorrect answers
to queries, even on Postgres 13? Why wouldn't that be enough, even if
we make the most pessimistic possible assumptions?
To me it looks like it's physically impossible to advance an XID past
xidStopLimit, unless you're in single user mode. Does your concern
have something to do with the actual xidStopLimit value in shared
memory not being sufficiently protective in practice?
> And even in 14+, you can still do that, if you use single user mode.
So what you're saying is that there is *some* reason for vacuuming in
single user mode after all, and so we should keep the advice about
that in place? :-)
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-02-16 20:31:16 | Re: Time to drop plpython2? |
| Previous Message | Heikki Linnakangas | 2022-02-16 20:17:10 | Re: check-world has suddenly started spewing stuff on stderr |