Postgres Pro
Downloads
Home   >   mailing lists

Re: Inval reliability, especially for inplace updates - Mailing list pgsql-hackers

From Nitin Motiani
Subject Re: Inval reliability, especially for inplace updates
Date
Msg-id CAH5HC9508Xvz4BVca8OCoDOv7pgHqAf85EqZkWMZ_Q2hAkebzg@mail.gmail.com
Whole thread Raw
In response to Inval reliability, especially for inplace updates  (Noah Misch <noah@leadboat.com>)
Responses Re: Inval reliability, especially for inplace updates
List pgsql-hackers
Tree view 
On Sat, Oct 12, 2024 at 5:47 PM Noah Misch <noah@leadboat.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

pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan
Next
From: Noah Misch
Date:
Subject: Re: Inval reliability, especially for inplace updates