Adding an LWLockHeldByMe()-like function that reports if any buffercontent lock is held

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Adding an LWLockHeldByMe()-like function that reports if any buffercontent lock is held
Дата
Msg-id CAH2-WznJFhRT_b=+M6CcYo4JJacEeDa1meQN2u4+nkWZf5+X7w@mail.gmail.com
обсуждение исходный текст
Ответы Re: Adding an LWLockHeldByMe()-like function that reports if anybuffer content lock is held  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
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 most cases.

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) ever called
index_form_tuple(), and ended up actually performing table access with
an exclusive buffer lock held, we'd at least be able to catch the bug
when assertions are enabled. A function that lets code assert that no
buffer locks are held, for the rare cases where external table access
is required seems like good general infrastructure.

Does this seem like a good idea? This could get pretty expensive if it
was overused, even by the standards of what we expect from
assertion-enabled builds, but we could make it optional if the
overhead got out of hand.

-- 
Peter Geoghegan


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Следующее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning