Message-ID: <00888abf-dbda-4a58-8af1-8de6a54f1f4e@wi3ck.info>
Date: Thu, 14 Nov 2024 08:50:31 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Commit Timestamp and LSN Inversion issue
To: Amit Kapila <amit.kapila16@gmail.com>, Tomas Vondra <tomas@vondra.me>
Cc: Andres Freund <andres@anarazel.de>,
 "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>,
 Aleksander Alekseev <aleksander@timescale.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 shveta malik <shveta.malik@gmail.com>, Jan Wieck <jan@wi3ck.info>
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>
 <9f7f4def-7ea8-4ad3-83e7-a8cc9d18c58a@wi3ck.info>
 <gkbrjxwyjbqckjbrkep3uy2mvrcq2mrfzprfmegbeiqxidtmbu@3cgs5iocjykk>
 <OS0PR01MB57162A227EC357482FEB4470945D2@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <xhcapr7lur35itqrbk4qdqn7rzfaqr3g6dvyxzfx6jeyknhvbv@h3wkgixuuuon>
 <CAA4eK1+ZdL=sC4sdUOQz+X9=7Z8Uxhkd0VqwcB9rgzXjvu=6yA@mail.gmail.com>
 <11ee3489-40ba-45d6-ba6a-7c3def725e84@vondra.me>
 <CAA4eK1KQ6H4u5=_5Xq44HhX3RFXW4HW-z0F4T4J1nf2xVCo04w@mail.gmail.com>
 <2c754a6c-478f-4a9e-9f3f-4ea6d8db5188@vondra.me>
 <CAA4eK1LZf5G2_HhqdHFC5Y67i2xmL=nV33FX-f5svXLMCQ4Omw@mail.gmail.com>
Content-Language: en-US
From: Jan Wieck <jan@wi3ck.info>
In-Reply-To: <CAA4eK1LZf5G2_HhqdHFC5Y67i2xmL=nV33FX-f5svXLMCQ4Omw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/00888abf-dbda-4a58-8af1-8de6a54f1f4e%40wi3ck.info>
Precedence: bulk

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