| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Cc: | "Schneider, Jeremy" <schnjere(at)amazon(dot)com> |
| Subject: | ERROR: multixact X from before cutoff Y found to be still running |
| Date: | 2019-09-05 00:37:40 |
| Message-ID: | DAFB8AFF-2F05-4E33-AD7F-FF8B0F760C17@amazon.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Hi,
Currently, if you hold a multixact open long enough to generate an
"oldest multixact is far in the past" message during VACUUM, you may
see the following ERROR:
WARNING: oldest multixact is far in the past
HINT: Close open transactions with multixacts soon to avoid wraparound problems.
ERROR: multixact X from before cutoff Y found to be still running
Upon further inspection, I found that this is because the multixact
limit used in this case is the threshold for which we emit the "oldest
multixact" message. Instead, I think the multixact limit should be
set to the result of GetOldestMultiXactId(), effectively forcing a
minimum freeze age of zero. The ERROR itself is emitted by
FreezeMultiXactId() and appears to be a safeguard against problems
like this.
I've attached a patch to set the limit to the oldest multixact instead
of the "safeMxactLimit" in this case. I'd like to credit Jeremy
Schneider as the original reporter.
Nathan
| Attachment | Content-Type | Size |
|---|---|---|
| fix_multixact_limit.patch | application/octet-stream | 1.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeremy Schneider | 2019-09-05 01:01:05 | Re: ERROR: multixact X from before cutoff Y found to be still running |
| Previous Message | PG Bug reporting form | 2019-09-05 00:24:23 | BUG #15991: Troubles about Management Tools for Postgre. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2019-09-05 00:46:26 | pg_promote() can cause busy loop |
| Previous Message | Tom Lane | 2019-09-05 00:25:22 | Re: Unexpected "shared memory block is still in use" |