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
|
Список | 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 по дате отправления: