public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jan Wieck <[email protected]>
To: Amit Kapila <[email protected]>
To: Tomas Vondra <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Zhijie Hou (Fujitsu) <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: shveta malik <[email protected]>
Cc: Jan Wieck <[email protected]>
Subject: Re: Commit Timestamp and LSN Inversion issue
Date: Thu, 14 Nov 2024 08:50:31 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA4eK1LZf5G2_HhqdHFC5Y67i2xmL=nV33FX-f5svXLMCQ4Omw@mail.gmail.com>
References: <CAJpy0uBxEJnabEp3JS=n9X19Vx2ZK3k5AR7N0h-cSMtOwYV3fA@mail.gmail.com>
<CAJ7c6TNZY3idBDoGOaoS_fF6vJuBMjnDhZC4i5V0J58s2SJ3AA@mail.gmail.com>
<CAA4eK1LOmtMpmJAxsmN0yXJb-Q9vi6KThDYXdpVGL_WZW5ZgvQ@mail.gmail.com>
<CAJ7c6TOcQPcydC7HW=xPEDN6_Ec7iSTP9j=1VTAeG=haguOQHw@mail.gmail.com>
<CAA4eK1KhAxe6=VTxa6xEbc22_VVBLsVuvRH8Wxws8i50gH=eqw@mail.gmail.com>
<[email protected]>
<gkbrjxwyjbqckjbrkep3uy2mvrcq2mrfzprfmegbeiqxidtmbu@3cgs5iocjykk>
<OS0PR01MB57162A227EC357482FEB4470945D2@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<xhcapr7lur35itqrbk4qdqn7rzfaqr3g6dvyxzfx6jeyknhvbv@h3wkgixuuuon>
<CAA4eK1+ZdL=sC4sdUOQz+X9=7Z8Uxhkd0VqwcB9rgzXjvu=6yA@mail.gmail.com>
<[email protected]>
<CAA4eK1KQ6H4u5=_5Xq44HhX3RFXW4HW-z0F4T4J1nf2xVCo04w@mail.gmail.com>
<[email protected]>
<CAA4eK1LZf5G2_HhqdHFC5Y67i2xmL=nV33FX-f5svXLMCQ4Omw@mail.gmail.com>
On 11/13/24 03:56, Amit Kapila wrote:
> the key point Andres
> is raising is that we won't be able to convert the operation in
> ReserveXLogInsertLocation() to use atomics after such a solution. Now,
> even, if the change is only in the *commit* code path, we may or may
> not be able to maintain two code paths for reserving LSN, one using
> atomics and the other (for commit record) using spinlock.
Which is only partially true. There is nothing that would prevent us
from using atomic operations inside of a spinlock and only reserving
xlog space for commit records needs a spinlock because of the extra
logic that cannot be combined into a single atomic operation. The idea
as I understand Andres is that changing ReserveXLogInsertLocation() to
use atomics gets rid not only of the spinlock, but also the LW-locks
that protect it from a spinlock storm.
Keeping the current LW-lock plus spinlock architecture only for commit
records but changing the actual reserve to atomic operations would
affect small transactions more than large ones. Making all of this
depend on "wal_level = logical" removes the argument that the two
solutions are mutually exclusive. It does however make the code less
maintenance friendly.
Best Regards, Jan
view thread (33+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Commit Timestamp and LSN Inversion issue
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox