Re: BUG #18259: Assertion in ExtendBufferedRelLocal() fails after no-space-left condition
От | Michael Paquier |
---|---|
Тема | Re: BUG #18259: Assertion in ExtendBufferedRelLocal() fails after no-space-left condition |
Дата | |
Msg-id | ZZEMZsgslgqfYzJH@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #18259: Assertion in ExtendBufferedRelLocal() fails after no-space-left condition (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: BUG #18259: Assertion in ExtendBufferedRelLocal() fails after no-space-left condition
|
Список | pgsql-bugs |
On Thu, Dec 28, 2023 at 02:36:46PM +0800, Richard Guo wrote: > On Wed, Dec 27, 2023 at 5:08 PM tender wang <tndrwang@gmail.com> wrote: (Tender Wang.. I know somebody with this name while doing Postgres stuff in the past, are you the same guy?) >> Yeah, that's true. I analyze this issue again, and I think the root cause >> is the " buf_state &= BM_VALID" . > > Nice catch. I believe the intention is to clear the BM_VALID bit. Hmm. Yeah. I'd need to think about that a bit more carefully, but it looks like you are right here.. Nice catch. That looks like an unfortunate typo from 31966b151e6a when local buffers are handled. > By the way, I wonder if it would be worthwhile to define new macros for > bit operations such as set_bit, clear_bit, test_bit, and so on, so that > we can avoid such typos in the future. Not sure. This is hiding the code behind more layers without bringing extra value if you know how to read bitwise operations, which is something I'd expect somebody to get pretty good at when hacking on Postgres because that's all around the code tree. And this would create conflict noises when backpatching. Hence, -1. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: