Re: Persist slot invalidations before publishing them - Mailing list pgsql-hackers

From shveta malik
Subject Re: Persist slot invalidations before publishing them
Date
Msg-id CAJpy0uDw2b+Ykx73E6Xk6Cgo1qL_HOkoOTEv0OU5VsHXkJm2WQ@mail.gmail.com
Whole thread
In response to Re: Persist slot invalidations before publishing them  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Persist slot invalidations before publishing them
List pgsql-hackers
On Mon, Oct 5, 2026 at 6:54 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> Hi,
>
> On Mon, Oct 05, 2026 at 03:22:53PM +0530, Ashutosh Sharma wrote:
> > Thanks. I'll review again once the updated patch is posted.
>
> Thanks! Here it is.
>

Since we have now modularized this further by introducing
SaveSlotToPathInternal() and SaveInvalidatedSlotToPath(), can we make
SaveSlotToPathInternal() consistent across both flows with respect to
lock acquisition and release?

We could have SaveSlotToPath() acquire and release the lock,
preferably within a PG_TRY/PG_CATCH block. Additionally, the
'was_dirty' check can also be moved up into SaveSlotToPath(), since
SaveInvalidatedSlotToPath() always forces a write and doesn't need the
check.

This way, SaveSlotToPath() would acquire the lock only when the slot
is dirty, and SaveSlotToPathInternal() would not need to handle lock
acquisition/release based on the 'cause' argument. This would also let
us remove the multiple if blocks that currently check the 'cause' and
release the lock. Thoughts?

thanks
Shveta



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Progress reporting: a debug trace and a test framework
Next
From: JoongHyuk Shin
Date:
Subject: Re: [PATCH] Extend MXactCache lifetime from per-transaction to per-session