Re: Weird test mixup
От | Michael Paquier |
---|---|
Тема | Re: Weird test mixup |
Дата | |
Msg-id | Zj1ykS1EsakW_niW@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Weird test mixup (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Weird test mixup
Re: Weird test mixup |
Список | pgsql-hackers |
On Thu, May 09, 2024 at 04:39:00PM -0700, Noah Misch wrote: Thanks for the feedback. > The return-bool approach sounds fine. Up to you whether to do in this patch, > else I'll do it when I add the test. I see no reason to not change the signature of the routine now if we know that we're going to do it anyway in the future. I was shortly wondering if doing the same for InjectionpointAttach() would make sense, but it has more error states, so I'm not really tempted without an actual reason (cannot think of a case where I'd want to put more control into a module after a failed attach). >> It could >> always be possible that a concurrent backend does a detach followed by >> an attach with the same name, causing the shmem exit callback to drop >> a point it should not, but that's not really a plausible case IMO :) > > Agreed. It's reasonable to expect test cases to serialize backend exits, > attach calls, and detach calls. If we need to fix that later, we can use > attachment serial numbers. Okay by me. > I'd name this INJ_CONDITION_UNCONDITIONAL or INJ_CONDITION_ALWAYS. INVALID > sounds like a can't-happen event or an injection point that never runs. > Otherwise, the patch looks good and makes src/test/modules/gin safe for > installcheck. Thanks. INJ_CONDITION_ALWAYS sounds like a good compromise here. Attached is an updated patch for now, indented with a happy CI. I am still planning to look at that a second time on Monday with a fresher mind, in case I'm missing something now. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: