Horton

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: David Rowley <dgrowleyml@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Jacob Champion <jchampion@timescale.com>, Yura Sokolov <y.sokolov@postgrespro.ru>, Zhihong Yu <zyu@yugabyte.com>, Michael Paquier <michael@paquier.xyz>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, "Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>, Andres Freund <andres@anarazel.de>, Simon Riggs <simon@2ndquadrant.com>, Amit Langote <amitlangote09@gmail.com>
Date: 2023-11-09T16:18:21Z
Lists: pgsql-hackers

Attachments

On 18/09/2023 07:08, David Rowley wrote:
> On Fri, 15 Sept 2023 at 22:37, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> I've added a call to LockAssertNoneHeld(false) in there.
>>
>> I don't see it in the patch?
> 
> hmm. I must've git format-patch before committing that part.
> 
> I'll try that again... see attached.

This needed a rebase after my ResourceOwner refactoring. Attached.

A few quick comments:

- It would be nice to add a test for the issue that you fixed in patch 
v7, i.e. if you prepare a transaction while holding session-level locks.

- GrantLockLocal() now calls MemoryContextAlloc(), which can fail if you 
are out of memory. Is that handled gracefully or is the lock leaked?

-- 
Heikki Linnakangas
Neon (https://neon.tech)

Commits

  1. Reorder LOCALLOCK structure members to compact the size

  2. Be more careful to not lose sync in the FE/BE protocol.