Re: do only critical work during single-user vacuum? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: do only critical work during single-user vacuum?
Date
Msg-id CA+TgmoY3m3RimCHifQnxU3YDVV7oYRbRUX4GZ4FuYkhnhe0giA@mail.gmail.com
Whole thread Raw
In response to Re: do only critical work during single-user vacuum?  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: do only critical work during single-user vacuum?  (John Naylor <john.naylor@enterprisedb.com>)
Re: do only critical work during single-user vacuum?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Feb 3, 2022 at 1:34 PM John Naylor <john.naylor@enterprisedb.com> wrote:
> The word "advice" sounds like people have a choice, rather than the
> system not accepting commands anymore. It would be much less painful
> if the system closed connections and forbade all but superusers to
> connect, but that sounds like a lot of work. (happy to be proven
> otherwise)

They *do* have a choice. They can continue to operate the system in
multi-user mode, they can have read access to their data, and they can
run VACUUM and other non-XID-allocating commands to fix the issue.
Sure, their application can't run commands that allocate XIDs, but
it's not going to be able to do that if they go to single-user mode
either.

I don't understand why we would want the system to stop accepting
connections other than superuser connections. That would provide
strictly less functionality and I don't understand what it would gain.
But it would still be better than going into single-user mode, which
provides even less functionality and has basically no advantages of
any kind.

Why are you convinced that the user HAS to go to single-user mode? I
don't think they have to do that, and I don't think they should want
to do that.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: do only critical work during single-user vacuum?
Next
From: Stephen Frost
Date:
Subject: Re: Support for NSS as a libpq TLS backend