Re: Add 64-bit XIDs into PostgreSQL 15

On 1/4/22, 2:35 PM, "Stephen Frost" <sfrost(at)snowman(dot)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-running transactions 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 XIDs and 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 resolve the 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 intermediate representation 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-bit XIDs simpler and more maintainable.

/Jim