`OrioleDB implements default 64-bit transaction identifiers, thus eliminating the well-known and painful wraparound problem`
I thought that PG's 32-bit transaction identifier and wraparound issue was due to the current MVCC implementation that keeps old versions of rows in page tables, so there is the need to vacuum to clean up the dead rows. So my assumption was that using another approach for MVCC, like the UNDO log, this problem wouldn't exist (since page tables would only have the latest version).
PostgreSQL 32-bit transaction identifiers are cycled in a ring. This is why PostgreSQL needs to "freeze" old transaction identifiers before they could start being identified as future. This routine is "vacuum freeze" and it have to scan and re-write pages, which could have no dead rows.
I dindn't get this:
`OrioleDB implements default 64-bit transaction identifiers, thus eliminating the well-known and painful wraparound problem`
I thought that PG's 32-bit transaction identifier and wraparound issue was due to the current MVCC implementation that keeps old versions of rows in page tables, so there is the need to vacuum to clean up the dead rows. So my assumption was that using another approach for MVCC, like the UNDO log, this problem wouldn't exist (since page tables would only have the latest version).
What am I missing here?