Re: MarkBufferDirty Assert held LW_EXCLUSIVE lock fail when ginFinishSplit

feichanghong <feichanghong@qq.com>

From: feichanghong <feichanghong@qq.com>

To: Heikki Linnakangas <hlinnaka@iki.fi>

Cc: Michael Paquier <michael@paquier.xyz>, pgsql-bugs <pgsql-bugs@lists.postgresql.org>

Date: 2024-01-22T16:21:58Z

Lists: pgsql-bugs

Commits

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

Fix locking when fixing an incomplete split of a GIN internal page
- e6511fe649c5 12.18 landed
- e74c916657b5 13.14 landed
- f120c0872427 14.11 landed
- e43425f48154 15.6 landed
- b899e00e716b 16.2 landed
- 6a1ea02c491d 17.0 landed
Add backend support for injection points
- d86d20f0ba79 17.0 cited

> From a performance point of view, this doesn't matter. Incomplete split are extremely rare. For convenience, though, I added a new function specifically for handling these "leftover" incomplete splits as opposed to finishing a split that you just made, which performs the lock-upgrade. See attached. I think that helps with readability, and makes it less likely that we'll forget the lock-upgrade in the future if the insertion code is refactored.
I think that the lock-upgrade in the ginFinishOldSplit function is unsafe
because it violates the requirement of the ginStepRight function that
"The next page is locked first, before releasing the current page.”


Best Regards,
Fei Changhong
Alibaba Cloud Computing Ltd.