database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-18 05:01:01 +03:00
Code Activity

Widen MultiXactOffset to 64 bits

Browse Source 
This eliminates MultiXactOffset wraparound and the 2^32 limit on the
total number of multixid members. Multixids are still limited to 2^31,
but this is a nice improvement because 'members' can grow much faster
than the number of multixids. On such systems, you can now run longer
before hitting hard limits or triggering anti-wraparound vacuums.

Not having to deal with MultiXactOffset wraparound also simplifies the
code and removes some gnarly corner cases.

We no longer need to perform emergency anti-wraparound freezing
because of running out of 'members' space, so the offset stop limit is
gone. But you might still not want 'members' to consume huge amounts
of disk space. For that reason, I kept the logic for lowering vacuum's
multixid freezing cutoff if a large amount of 'members' space is
used. The thresholds for that are roughly the same as the "safe" and
"danger" thresholds used before, 2 billion transactions and 4 billion
transactions. This keeps the behavior for the freeze cutoff roughly
the same as before. It might make sense to make this smarter or
configurable, now that the threshold is only needed to manage disk
usage, but that's left for the future.

Add code to pg_upgrade to convert multitransactions from the old to
the new format, rewriting the pg_multixact SLRU files. Because
pg_upgrade now rewrites the files, we can get rid of some hacks we had
put in place to deal with old bugs and upgraded clusters. Bump catalog
version for the pg_multixact/offsets format change.

Author: Maxim Orlov <orlovmg@gmail.com>
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com>
Discussion: https://www.postgresql.org/message-id/CACG%3DezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com
This commit is contained in:
Heikki Linnakangas
2025-12-09 13:53:03 +02:00
parent bb3b1c4f64
commit bd8d9c9bdf
29 changed files with 1607 additions and 520 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/src/sgml/ref/pg_resetwal.sgml
View File

@@ -267,14 +267,17 @@ PostgreSQL documentation
A safe value for the next multitransaction ID (first part) can be
determined by looking for the numerically largest file name in the
directory <filename>pg_multixact/offsets</filename> under the data directory,
adding one, and then multiplying by 65536 (0x10000). Conversely, a safe
adding one, and then multiplying by 32768 (0x8000). Conversely, a safe
value for the oldest multitransaction ID (second part of
<option>-m</option>) can be determined by looking for the numerically smallest
file name in the same directory and multiplying by 65536. The file
names are in hexadecimal, so the easiest way to do this is to specify
the option value in hexadecimal and append four zeroes.
file name in the same directory and multiplying by 32768 (0x8000).
Note that the file names are in hexadecimal. It is usually easiest
to specify the option value in hexadecimal too. For example, if
<filename>000F</filename> and <filename>0007</filename> are the greatest and
smallest entries in <filename>pg_multixact/offsets</filename>,
<literal>-m 0x80000,0x38000</literal> will work.
</para>
<!-- 65536 = SLRU_PAGES_PER_SEGMENT * BLCKSZ / sizeof(MultiXactOffset) -->
<!-- 32768 = SLRU_PAGES_PER_SEGMENT * BLCKSZ / sizeof(MultiXactOffset) -->
</listitem>
</varlistentry>