On 1/4/22, 2:35 PM, "Stephen Frost" <sfrost@snowman.net> wrote:
>>
>> Not saying that I've got any idea how to fix that case offhand, and we
>> don't really support such a thing today as the server would just stop
>> instead, ...
>> Perhaps that's a
>> worthwhile tradeoff for being able to generally avoid having to vacuum
>> and deal with transaction wrap-around, but I have to wonder if there
>> might be a better answer.
>>
For the target use cases that PostgreSQL is designed for, it's a very worthwhile tradeoff in my opinion. Such
long-runningtransactions need to be killed.
Re: -- If after upgrade page has no free space for special data, tuples are
converted to "double xmax" format: xmin became virtual
FrozenTransactionId, xmax occupies the whole 64bit.
Page converted to new format when vacuum frees enough space.
I'm concerned about the maintainability impact of having 2 new on-disk page formats. It's already complex enough with
XIDsand multixact-XIDs.
If the lack of space for the two epochs in the special data area is a problem only in an upgrade scenario, why not
resolvethe problem before completing the upgrade process like a kind of post-process pg_repack operation that converts
all"double xmax" pages to the "double-epoch" page format? i.e. maybe the "double xmax" representation is needed as an
intermediaterepresentation during upgrade, but after upgrade completes successfully there are no pages with the
"double-xmax"representation. This would eliminate a whole class of coding errors and would make the code dealing with
64-bitXIDs simpler and more maintainable.
/Jim