| From: | Nitin Motiani <nitinmotiani(at)google(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Inval reliability, especially for inplace updates |
| Date: | 2024-10-12 12:35:06 |
| Message-ID: | CAH5HC9508Xvz4BVca8OCoDOv7pgHqAf85EqZkWMZ_Q2hAkebzg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Oct 12, 2024 at 5:47 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
>
> Rebased.
Hi,
I have a couple of questions :
1. In heap_inplace_update_and_unlock, currently both buffer and tuple
are unlocked outside the critical section. Why do we have to move the
buffer unlock within the critical section here? My guess is that it
needs to be unlocked for the inplace invals to be processed. But what
is the reasoning behind that?
2. Is there any benefit in CacheInvalidateHeapTupleCommon taking the
preapre_callback argument? Wouldn't it be simpler to just pass an
InvalidationInfo* to the function?
Also is inval-requires-xid-v0.patch planned to be fixed up to inplace160?
Thanks
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shinoda, Noriyoshi (SXD Japan FSIP) | 2024-10-12 13:02:55 | RE: Statistics Import and Export |
| Previous Message | Alexander Lakhin | 2024-10-12 11:00:00 | Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan |