forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit2a9b019
committed
Cope with possible failure of the oldest MultiXact to exist.
Recent commits, mainlyb69bf30 and53bb309, introduced mechanisms toprotect against wraparound of the MultiXact member space: the numberof multixacts that can exist at one time is limited to 2^32, but thetotal number of members in those multixacts is also limited to 2^32,and older code did not take care to enforce the second limit,potentially allowing old data to be overwritten while it was stillneeded.Unfortunately, these new mechanisms failed to account for the factthat the code paths in which they run might be executed duringrecovery or while the cluster was in an inconsistent state. Also,they failed to account for the fact that users who used pg_upgradeto upgrade a PostgreSQL version between 9.3.0 and 9.3.4 might havemight oldestMultiXid = 1 in the control file despite the true valuebeing larger.To fix these problems, first, avoid unnecessarily examining themmembers of MultiXacts when the cluster is not known to be consistent.TruncateMultiXact has done this for a long time, and this patch doesnot fix that. But the new calls used to prevent member wraparoundare not needed until we reach normal running, so avoid calling themearlier. (SetMultiXactIdLimit is actually called before InRecoveryis set, so we can't rely on that; we invent our own multixact-specificflag instead.)Second, make failure to look up the members of a MultiXact a non-fatalerror. Instead, if we're unable to determine the member offset atwhich wraparound would occur, postpone arming the member wraparounddefenses until we are able to do so. If we're unable to determine themember offset that should force autovacuum, force it continuouslyuntil we are able to do so. If we're unable to deterine the memberoffset at which we should truncate the members SLRU, log a message andskip truncation.An important consequence of these changes is that anyone who does havea bogus oldestMultiXid = 1 value in pg_control will experienceimmediate emergency autovacuuming when upgrading to a release thatcontains this fix. The release notes should highlight this fact. Ifa user has no pg_multixact/offsets/0000 file, but has oldestMultiXid = 1in the control file, they may wish to vacuum any tables withrelminmxid = 1 prior to upgrading in order to avoid an immediateemergency autovacuum after the upgrade. This must be done with aPostgreSQL version 9.3.5 or newer and with vacuum_multixact_freeze_min_ageand vacuum_multixact_freeze_table_age set to 0.This patch also adds an additional log message at each database serverstartup, indicating either that protections against member wraparoundhave been engaged, or that they have not. In the latter case, onceautovacuum has advanced oldestMultiXid to a sane value, the messageindicating that the guards have been engaged will appear at the nextcheckpoint. A few additional messages have also been added at the DEBUG1level so that the correct operation of this code can be properly audited.Along the way, this patch fixes another, related bug in TruncateMultiXactthat has existed since PostgreSQL 9.3.0: when no MultiXacts exist atall, the truncation code looks up NextMultiXactId, which doesn't existyet. This can lead to TruncateMultiXact removing every file inpg_multixact/offsets instead of keeping one around, as it should.This in turn will cause the database server to refuse to startafterwards.Patch by me. Review by Álvaro Herrera, Andres Freund, Noah Misch, andThomas Munro.1 parent746092a commit2a9b019
1 file changed
+233
-74
lines changed0 commit comments
Comments
(0)