Hi, On 2022-02-03 13:42:20 -0500, Robert Haas wrote: > 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 wonder if we shouldn't add some exceptions to the xid allocation prevention. It makes sense that we don't allow random DML. But it's e.g. often more realistic to drop / truncate a few tables with unimportant content, rather than spend the time vacuuming those. We could e.g. allow xid consumption within VACUUM, TRUNCATE, DROP TABLE / INDEX when run at the top level for longer than we allow it for anything else. > 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. Indeed. Single user is the worst response to this (and just about anything else, really). Even just getting into the single user mode takes a while (shutdown checkpoint). The user interface is completely different (and awful). The buffer cache is completely cold. The system is slower because there's no wal writer / checkpointer running. Which basically is a list of things one absolutely do not wants when confronted with a wraparound situation. Greetings, Andres Freund
