On Wed, Apr 18, 2018 at 6:53 PM, Michael Paquier wrote:
>> I'm curious about what we'll find by just by adding
>> Assert(!AnyBufferLockHeldByMe()) to the top of
>> heap_tuple_fetch_attr(). AssertNotInCriticalSection() certainly found
>> several bugs when it was first added.
>
> Yep.
I wrote a sim
On Wed, Apr 18, 2018 at 06:44:00PM -0700, Peter Geoghegan wrote:
> What I have in mind here is something that's a bit like
> AssertNotInCriticalSection(). We don't need to pepper
> AssertNotInCriticalSection() everywhere in practice, because calling
> palloc() is a pretty good proxy for "function s
On Wed, Apr 18, 2018 at 5:46 PM, Michael Paquier wrote:
> Personally, I favor approaches like that, because it allows to catch up
> problems in using some APIs when people working on a patch miss any kind
> of warning comments at the top of the function or within it which
> summarize the condition
On Wed, Apr 18, 2018 at 04:53:29PM -0700, Peter Geoghegan wrote:
> It occurred to me that it would be nice to be able to
> Assert(!AnyBufferLockHeldByMe()) at a certain point within
> index_form_tuple(), to make sure that our assumptions hold. If
> index_truncate_tuple() (or any other function) eve
During recent review of the INCLUDE covering index patch, I pushed to
formalize the slightly delicate assumptions that we make around how
index_truncate_tuple() is called. It's natural to call
index_truncate_tuple() during a page split, when a buffer lock is
held. This is what we actually do in mos
