| 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
| 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 |