On Sat, Apr 29, 2023 at 1:09 AM John Naylor
<john.naylor@enterprisedb.com> wrote:
> Looks good to me.
I'm strongly in favor of this. It's most unfortunate that it took this long.
> I've just made some small edits for v7 and wrote a commit message to explain how we got here. This can be backpatched
allthe way, as it's simply a correction.
+1 to backpatching at least back until v14. After all, it wouldn't
make any sense for us to not backpatch to 14; the whole justification
for doing this was in no way influenced by anything that happened
since the failsafe went in.
I'm also in favor of backpatching to 11, 12, and 13 -- though I
acknowledge that that's more of a judgement call. As you note in
comments in the draft patch, the story with these earlier releases
(especially 11) is a little more complicated for users.
> I made some small changes and wrote a suitably comprehensive commit message. I separated the possible uses for
single-usermode into a separate paragraph in the "Note:" , moved the justification for the 3-million xid margin there,
andrestored the link to how to run it (I already mentioned we still need this info, but didn't notice this part didn't
makeit 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".
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.
Do we need two new names? One for xidStopLimit, another for
multiStopLimit? The latter really can't be called read-only mode.
> 0003:
>
> It really needs a more comprehensive change, and just making a long hint even longer doesn't seem worth doing. I'd
liketo set that aside and come back to it. I've left it out of the attached set.
Yeah, 0003 can be treated as independent work IMV.
--
Peter Geoghegan