| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Dmitry Yurichev <dsy(dot)075(at)yandex(dot)ru>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Ivan Bykov <i(dot)bykov(at)modernsys(dot)ru>, Kirill Reshke <reshkekirill(at)gmail(dot)com> |
| Subject: | Re: IPC/MultixactCreation on the Standby server |
| Date: | 2025-12-04 14:36:01 |
| Message-ID: | 202512041432.ei3eovzqjg5j@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2025-Dec-04, Heikki Linnakangas wrote:
> While working on the 64-bit multixid offsets patch, I noticed one more bug
> with this. At offset wraparound, when we set the next multixid's offset in
> RecordNewMultiXact, we incorrectly set it to 0 instead of 1. We're supposed
> to skip over offset 1, because 0 is reserved to mean invalid. We do that
> correctly when setting the "current" multixid's offset, because the caller
> of RecordNewMultiXact has already skipped over offset 0, but I missed it for
> the next offset.
Ouch.
> I tried to modify the new wraparound TAP test to reproduce that, but it
> turned out to be difficult because you need to have multiple backends
> assigning multixids concurrently to hit that.
Hmm, would it make sense to add a pgbench-based test on
src/test/modules/xid_wraparound? That module is already known to be
expensive, and it doesn't run unless explicitly enabled, so I think it's
not a bad fit.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | vignesh C | 2025-12-04 14:35:31 | Re: Proposal: Conflict log history table for Logical Replication |