From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Fix bug in SetOffsetVacuumLimit() triggered by find_multixact_st |
Date: | 2015-12-14 10:55:28 |
Message-ID: | E1a8Qmu-0004DX-5e@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Fix bug in SetOffsetVacuumLimit() triggered by find_multixact_start() failure.
Previously, if find_multixact_start() failed, SetOffsetVacuumLimit() would
install 0 into MultiXactState->offsetStopLimit if it previously succeeded.
Luckily, there are no known cases where find_multixact_start() will return
an error in 9.5 and above. But if it were to happen, for example due to
filesystem permission issues, it'd be somewhat bad: GetNewMultiXactId()
could continue allocating mxids even if close to a wraparound, or it could
erroneously stop allocating mxids, even if no wraparound is looming. The
wrong value would be corrected the next time SetOffsetVacuumLimit() is
called, or by a restart.
Reported-By: Noah Misch, although this is not his preferred fix
Discussion: 20151210140450(dot)GA22278(at)alap3(dot)anarazel(dot)de
Backpatch: 9.5, where the bug was introduced as part of 4f627f
Branch
------
REL9_5_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/ccde00b9b97ed8b7307e39f95bd48922bf955bb2
Modified Files
--------------
src/backend/access/transam/multixact.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-12-14 15:21:38 | Re: [COMMITTERS] pgsql: pg_rewind: Don't error if the two clusters are already on the sa |
Previous Message | Andres Freund | 2015-12-14 10:55:25 | pgsql: Fix bug in SetOffsetVacuumLimit() triggered by find_multixact_st |