Horton
Menu

Re: IPC/MultixactCreation on the Standby server

Heikki Linnakangas <hlinnaka@iki.fi>

View thread
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Dmitry Yurichev <dsy.075@yandex.ru>, Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, pgsql-hackers@lists.postgresql.org, Ivan Bykov <i.bykov@modernsys.ru>, Kirill Reshke <reshkekirill@gmail.com>
Date: 2025-12-04T14:17:53Z
Lists: pgsql-hackers

Attachments

On 03/12/2025 19:19, Heikki Linnakangas wrote:
> On 03/12/2025 16:19, Dmitry Yurichev wrote:
>> On 12/2/25 16:48, Heikki Linnakangas wrote:
>>> Thanks! Agreed, v14-16 were the same. v17 and v18 might be worth 
>>> testing separately, to make sure I didn't e.g. screw up the locking 
>>> differences.
>>
>> I tested on the REL_18_1 tag (with applying v15-pg18-0001-Set-next- 
>> multixid-s-offset-when-creating-a-.patch).
>> I didn't notice any deadlocks or other errors. Thanks!
> 
> Okay. I fixed a few more little things:
> 
> - fixed the warnings about shadowed variables that Andrey pointed out
> - in older branches before we switched to 64-bit SLRU page numbers, use 
> 'int' rather than 'int64' in page number variables
> - improve wording and fix few trivial typos in comments
> 
> Committed with those last-minute changes. Thanks for the testing!

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.

I was able to reproduce that with these steps:

pg_resetwal -O 0xffffff00 -D data
pg_ctl -D data start
pgbench -s5 -i postgres
pgbench -c3 -t100 -f a.sql postgres

a.sql:
select * from pgbench_branches FOR KEY SHARE;

You get an error like this:

pgbench: error: client 2 script 0 aborted in command 0 query 0: ERROR: 
MultiXact 372013 has invalid next offset

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.

The fix is pretty straightforward, see attached. Barring objections, 
I'll commit and backport this.

- Heikki

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix test to work with non-8kB block sizes

  2. Fix setting next multixid's offset at offset wraparound

  3. Add test for multixid wraparound

  4. Set next multixid's offset when creating a new multixid

  5. psql: Improve tab completion for large objects.

  6. Refactor some repetitive SLRU code

  7. Transaction IDs wrap around, per my proposal of 13-Aug-01. More