Re: Add 64-bit XIDs into PostgreSQL 15

Hi,

On 2022-01-24 16:38:54 +0400, Pavel Borisov wrote:
> +64-bit Transaction ID's (XID)
> +=============================
> +
> +A limited number (N = 2^32) of XID's required to do vacuum freeze to prevent
> +wraparound every N/2 transactions. This causes performance degradation due
> +to the need to exclusively lock tables while being vacuumed. In each
> +wraparound cycle, SLRU buffers are also being cut.

What exclusive lock?

> +"Double XMAX" page format
> +---------------------------------
> +
> +At first read of a heap page after pg_upgrade from 32-bit XID PostgreSQL
> +version pd_special area with a size of 16 bytes should be added to a page.
> +Though a page may not have space for this. Then it can be converted to a
> +temporary format called "double XMAX".
>
> +All tuples after pg-upgrade would necessarily have xmin = FrozenTransactionId.

Why would a tuple after pg-upgrade necessarily have xmin =
FrozenTransactionId? A pg_upgrade doesn't scan the tables, so the pg_upgrade
itself doesn't do anything to xmins.

I guess you mean that the xmin cannot be needed anymore, because no older
transaction can be running?

> +In-memory tuple format
> +----------------------
> +
> +In-memory tuple representation consists of two parts:
> +- HeapTupleHeader from disk page (contains all heap tuple contents, not only
> +header)
> +- HeapTuple with additional in-memory fields
> +
> +HeapTuple for each tuple in memory stores t_xid_base/t_multi_base - a copies of
> +page's pd_xid_base/pd_multi_base. With tuple's 32-bit t_xmin and t_xmax from
> +HeapTupleHeader they are used to calculate actual 64-bit XMIN and XMAX:
> +
> +XMIN = t_xmin + t_xid_base. (3)
> +XMAX = t_xmax + t_xid_base/t_multi_base. (4)

What identifies a HeapTuple as having this additional data?

> +The downside of this is that we can not use tuple's XMIN and XMAX right away.
> +We often need to re-read t_xmin and t_xmax - which could actually be pointers
> +into a page in shared buffers and therefore they could be updated by any other
> +backend.

Ugh, that's not great.

> +Upgrade from 32-bit XID versions
> +--------------------------------
> +
> +pg_upgrade doesn't change pages format itself. It is done lazily after.
> +
> +1. At first heap page read, tuples on a page are repacked to free 16 bytes
> +at the end of a page, possibly freeing space from dead tuples.

That will cause a *massive* torrent of writes after an upgrade. Isn't this
practically making pg_upgrade useless? Imagine a huge cluster where most of
the pages are all-frozen, upgraded using link mode.

What happens if the first access happens on a replica?

What is the approach for dealing with multixact files? They have xids
embedded? And currently the SLRUs will break if you just let the offsets SLRU
grow without bounds.

> +void
> +convert_page(Relation rel, Page page, Buffer buf, BlockNumber blkno)
> +{
> + PageHeader hdr = (PageHeader) page;
> + GenericXLogState *state = NULL;
> + Page tmp_page = page;
> + uint16 checksum;
> +
> + if (!rel)
> + return;
> +
> + /* Verify checksum */
> + if (hdr->pd_checksum)
> + {
> + checksum = pg_checksum_page((char *) page, blkno);
> + if (checksum != hdr->pd_checksum)
> + ereport(ERROR,
> + (errcode(ERRCODE_INDEX_CORRUPTED),
> + errmsg("page verification failed, calculated checksum %u but expected %u",
> + checksum, hdr->pd_checksum)));
> + }
> +
> + /* Start xlog record */
> + if (!XactReadOnly && XLogIsNeeded() && RelationNeedsWAL(rel))
> + {
> + state = GenericXLogStart(rel);
> + tmp_page = GenericXLogRegisterBuffer(state, buf, GENERIC_XLOG_FULL_IMAGE);
> + }
> +
> + PageSetPageSizeAndVersion((hdr), PageGetPageSize(hdr),
> + PG_PAGE_LAYOUT_VERSION);
> +
> + if (was_32bit_xid(hdr))
> + {
> + switch (rel->rd_rel->relkind)
> + {
> + case 'r':
> + case 'p':
> + case 't':
> + case 'm':
> + convert_heap(rel, tmp_page, buf, blkno);
> + break;
> + case 'i':
> + /* no need to convert index */
> + case 'S':
> + /* no real need to convert sequences */
> + break;
> + default:
> + elog(ERROR,
> + "Conversion for relkind '%c' is not implemented",
> + rel->rd_rel->relkind);
> + }
> + }
> +
> + /*
> + * Mark buffer dirty unless this is a read-only transaction (e.g. query
> + * is running on hot standby instance)
> + */
> + if (!XactReadOnly)
> + {
> + /* Finish xlog record */
> + if (XLogIsNeeded() && RelationNeedsWAL(rel))
> + {
> + Assert(state != NULL);
> + GenericXLogFinish(state);
> + }
> +
> + MarkBufferDirty(buf);
> + }
> +
> + hdr = (PageHeader) page;
> + hdr->pd_checksum = pg_checksum_page((char *) page, blkno);
> +}

Wait. So you just modify the page without WAL logging or marking it dirty on a
standby? I fail to see how that can be correct.

Imagine the cluster is promoted, the page is dirtied, and we write it
out. You'll have written out a completely changed page, without any WAL
logging. There's plenty other scenarios.

Greetings,

Andres Freund