Re: Persist slot invalidations before publishing them

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, JoongHyuk Shin <sjh910805(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Rui Zhao <zhaorui126(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Persist slot invalidations before publishing them
Date: 2026-10-06 04:55:35
Message-ID: CAJpy0uDw2b+Ykx73E6Xk6Cgo1qL_HOkoOTEv0OU5VsHXkJm2WQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 5, 2026 at 6:54 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message JoongHyuk Shin 2026-10-06 05:04:58 Re: [PATCH] Extend MXactCache lifetime from per-transaction to per-session
Previous Message Michael Paquier 2026-10-06 04:23:28 Re: Progress reporting: a debug trace and a test framework