database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-05 07:21:24 +03:00
Code Activity

Fix handling of multixacts predating pg_upgrade

Browse Source 
After pg_upgrade, it is possible that some tuples' Xmax have multixacts
corresponding to the old installation; such multixacts cannot have
running members anymore.  In many code sites we already know not to read
them and clobber them silently, but at least when VACUUM tries to freeze
a multixact or determine whether one needs freezing, there's an attempt
to resolve it to its member transactions by calling GetMultiXactIdMembers,
and if the multixact value is "in the future" with regards to the
current valid multixact range, an error like this is raised:
    ERROR:  MultiXactId 123 has not been created yet -- apparent wraparound
and vacuuming fails.  Per discussion with Andrew Gierth, it is completely
bogus to try to resolve multixacts coming from before a pg_upgrade,
regardless of where they stand with regards to the current valid
multixact range.

It's possible to get from under this problem by doing SELECT FOR UPDATE
of the problem tuples, but if tables are large, this is slow and
tedious, so a more thorough solution is desirable.

To fix, we realize that multixacts in xmax created in 9.2 and previous
have a specific bit pattern that is never used in 9.3 and later (we
already knew this, per comments and infomask tests sprinkled in various
places, but we weren't leveraging this knowledge appropriately).
Whenever the infomask of the tuple matches that bit pattern, we just
ignore the multixact completely as if Xmax wasn't set; or, in the case
of tuple freezing, we act as if an unwanted value is set and clobber it
without decoding.  This guarantees that no errors will be raised, and
that the values will be progressively removed until all tables are
clean.  Most callers of GetMultiXactIdMembers are patched to recognize
directly that the value is a removable "empty" multixact and avoid
calling GetMultiXactIdMembers altogether.

To avoid changing the signature of GetMultiXactIdMembers() in back
branches, we keep the "allow_old" boolean flag but rename it to
"from_pgupgrade"; if the flag is true, we always return an empty set
instead of looking up the multixact.  (I suppose we could remove the
argument in the master branch, but I chose not to do so in this commit).

This was broken all along, but the error-facing message appeared first
because of commit 8e9a16ab8f and was partially fixed in a25c2b7c4d.
This fix, backpatched all the way back to 9.3, goes approximately in the
same direction as a25c2b7c4d but should cover all cases.

Bug analysis by Andrew Gierth and Álvaro Herrera.

A number of public reports match this bug:
  https://www.postgresql.org/message-id/20140330040029.GY4582@tamriel.snowman.net
  https://www.postgresql.org/message-id/538F3D70.6080902@publicrelay.com
  https://www.postgresql.org/message-id/556439CF.7070109@pscs.co.uk
  https://www.postgresql.org/message-id/SG2PR06MB0760098A111C88E31BD4D96FB3540@SG2PR06MB0760.apcprd06.prod.outlook.com
  https://www.postgresql.org/message-id/20160615203829.5798.4594@wrigleys.postgresql.org
This commit is contained in:
Alvaro Herrera
2016-06-24 18:29:28 -04:00
parent 07f69137b1
commit d372cb173e
5 changed files with 86 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
src/backend/access/transam/multixact.c
View File

@ -1181,19 +1181,25 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
/*
* GetMultiXactIdMembers
* Returns the set of MultiXactMembers that make up a MultiXactId
* Return the set of MultiXactMembers that make up a MultiXactId
*
* If the given MultiXactId is older than the value we know to be oldest, we
* return -1. The caller is expected to allow that only in permissible cases,
* i.e. when the infomask lets it presuppose that the tuple had been
* share-locked before a pg_upgrade; this means that the HEAP_XMAX_LOCK_ONLY
* needs to be set, but HEAP_XMAX_KEYSHR_LOCK and HEAP_XMAX_EXCL_LOCK are not
* set.
* Return value is the number of members found, or -1 if there are none,
* and *members is set to a newly palloc'ed array of members. It's the
* caller's responsibility to free it when done with it.
*
* Other border conditions, such as trying to read a value that's larger than
* the value currently known as the next to assign, raise an error. Previously
* these also returned -1, but since this can lead to the wrong visibility
* results, it is dangerous to do that.
* from_pgupgrade must be passed as true if and only if only the multixact
* corresponds to a value from a tuple that was locked in a 9.2-or-older
* installation and later pg_upgrade'd (that is, the infomask is
* HEAP_LOCKED_UPGRADED). In this case, we know for certain that no members
* can still be running, so we return -1 just like for an empty multixact
* without any further checking. It would be wrong to try to resolve such a
* multixact: either the multixact is within the current valid multixact
* range, in which case the returned result would be bogus, or outside that
* range, in which case an error would be raised.
*
* In all other cases, the passed multixact must be within the known valid
* range, that is, greater to or equal than oldestMultiXactId, and less than
* nextMXact. Otherwise, an error is raised.
*
* onlyLock must be set to true if caller is certain that the given multi
* is used only to lock tuples; can be false without loss of correctness,
@ -1202,7 +1208,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
*/
int
GetMultiXactIdMembers(MultiXactId multi, MultiXactMember **members,
bool allow_old, bool onlyLock)
bool from_pgupgrade, bool onlyLock)
{
int pageno;
int prev_pageno;
@ -1221,7 +1227,7 @@ GetMultiXactIdMembers(MultiXactId multi, MultiXactMember **members,
debug_elog3(DEBUG2, "GetMembers: asked for %u", multi);
if (!MultiXactIdIsValid(multi))
if (!MultiXactIdIsValid(multi) || from_pgupgrade)
return -1;
/* See if the MultiXactId is in the local cache */
@ -1254,18 +1260,11 @@ GetMultiXactIdMembers(MultiXactId multi, MultiXactMember **members,
*
* An ID older than MultiXactState->oldestMultiXactId cannot possibly be
* useful; it has already been removed, or will be removed shortly, by
* truncation. Returning the wrong values could lead to an incorrect
* visibility result. However, to support pg_upgrade we need to allow an
* empty set to be returned regardless, if the caller is willing to accept
* it; the caller is expected to check that it's an allowed condition
* (such as ensuring that the infomask bits set on the tuple are
* consistent with the pg_upgrade scenario). If the caller is expecting
* this to be called only on recently created multis, then we raise an
* error.
* truncation. If one is passed, an error is raised.
*
* Conversely, an ID >= nextMXact shouldn't ever be seen here; if it is
* seen, it implies undetected ID wraparound has occurred. This raises a
* hard error.
* Also, an ID >= nextMXact shouldn't ever be seen here; if it is seen, it
* implies undetected ID wraparound has occurred. This raises a hard
* error.
*
* Shared lock is enough here since we aren't modifying any global state.
* Acquire it just long enough to grab the current counter values. We may
@ -1281,7 +1280,7 @@ GetMultiXactIdMembers(MultiXactId multi, MultiXactMember **members,
if (MultiXactIdPrecedes(multi, oldestMXact))
{
ereport(allow_old ? DEBUG1 : ERROR,
ereport(ERROR,
(errcode(ERRCODE_INTERNAL_ERROR),
errmsg("MultiXactId %u does no longer exist -- apparent wraparound",
multi)));