Re: out-of-order XID insertion in KnownAssignedXids
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-10-12T02:49:01Z
Lists: pgsql-hackers
Attachments
- duplicated-xids-recovery.patch (text/x-diff) patch
On Thu, Oct 11, 2018 at 08:04:11PM +0300, Konstantin Knizhnik wrote: > Proposed patch is attached. The problem I have with this patch doing the duplication removal and qsort work in LogCurrentRunningXacts is that it would still lock ProcArrayLock until the WAL record has been written with wal_level = logical. With many sessions and 2PC transactions running around, this would be a performance impact for any deployments every time a checkpoint happens or every time the bgwriter decide to log a standby snapshot. Hence I would go instead with the attached, which does the legwork at recovery, which is a one-time code path as you mentioned. Okay, this makes the recovery a bit longer but that's way better than impacting all deployments of Postgres, even those not using 2PC when normally running. And as the sorting phase already happens we just need to do something like the attached. One thing that we could also do for HEAD is to add in RunningTransactionsData if the transaction comes from a 2PC entry, and allow recovery to do more sanity checks. This would require a WAL format change. The proposed patch needs to be back-patched down to 9.3. -- Michael
Commits
-
Avoid duplicate XIDs at recovery when building initial snapshot
- 0c99e71965d3 9.3.25 landed
- 7c525519d802 9.4.20 landed
- d83dac37447c 9.5.15 landed
- 010041ddcc39 9.6.11 landed
- 8384ff42486e 10.6 landed
- 18781cd2af97 11.0 landed
- 1df21ddb19c6 12.0 landed