Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound

On Sun, Apr 30, 2023 at 4:15 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Sat, Apr 29, 2023 at 1:09 AM John Naylor
> <john(dot)naylor(at)enterprisedb(dot)com> wrote:

> > I made some small changes and wrote a suitably comprehensive commit
message. I separated the possible uses for single-user mode into a separate
paragraph in the "Note:" , moved the justification for the 3-million xid
margin there, and restored the link to how to run it (I already mentioned
we still need this info, but didn't notice this part didn't make it back
in).
>
> I notice that you've called xidStopLimit "read-only mode" in the docs.
> I think that it makes sense that you wouldn't use the term
> xidStopLimit here, but I'm not sure about this terminology, either. It
> seems to me that it should be something quite specific, since we're
> talking about a very specific mechanism. Whatever it is, It shouldn't
> contain the word "wraparound".

How about

-HINT: To avoid a database shutdown, [...]
+HINT: To prevent XID exhaustion, [...]

...and "MXID", respectively? We could explain in the docs that vacuum and
read-only queries still work "when XIDs have been exhausted", etc.

(I should probably also add in the commit message that the "shutdown" in
the message was carried over to MXIDs when they arrived also in 2005).

> Separately, there is a need to update a couple of other places to use
> this new terminology. The documentation for vacuum_sailsafe_age and
> vacuum_multixact_failsafe_age refer to "system-wide transaction ID
> wraparound failure", which seems less than ideal, even without your
> patch.

Right, I'll have a look.

> Do we need two new names? One for xidStopLimit, another for
> multiStopLimit? The latter really can't be called read-only mode.

Thanks for that correction.

Somewhat related to the now-postponed 0003: I think the docs would do well
to have ordered steps for recovering from both XID and MXID exhaustion. The
previous practice of shutting down had the side-effect of e.g. rolling back
all in-progress transactions whose XID appeared in a MXID but if you remain
in normal mode there is a bit more to check. Manual VACUUM will warn about
"cutoff for removing and freezing tuples is far in the past", but the docs
should be clear on this.

--
John Naylor
EDB: http://www.enterprisedb.com