| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Zhang Mingli <zmlpostgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg15b4: FailedAssertion("TransactionIdIsValid(xmax) |
| Date: | 2022-09-11 22:44:38 |
| Message-ID: | CA+hUKGJij=w7QssYsEVLp-F0ms5-GOzT0t99zKsLM+RbWL6K_Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Sep 10, 2022 at 5:44 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> < 2022-09-09 19:37:25.835 CDT telsasoft >ERROR: MultiXactId 133553154 has not been created yet -- apparent wraparound
I guess what happened here is that after one of your (apparently
several?) OOM crashes, crash recovery didn't run all the way to the
true end of the WAL due to the maintenance_io_concurrency=0 bug. In
the case you reported, it couldn't complete an end-of-recovery
checkpoint until you disabled recovery_prefetch, but that's only
because of the somewhat unusual way that vismap pages work. In
another case it might have been able to (bogusly) complete a
checkpoint, leaving things in an inconsistent state.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-09-12 00:08:50 | Re: Bump MIN_WINNT to 0x0600 (Vista) as minimal runtime in 16~ |
| Previous Message | Thomas Munro | 2022-09-11 22:31:49 | Re: pg15b4: FailedAssertion("TransactionIdIsValid(xmax) |