From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Weird test mixup |
Date: | 2024-05-09 04:47:45 |
Message-ID: | ZjxVcbsIy4tq3uhV@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 08, 2024 at 08:15:53PM -0700, Noah Misch wrote:
> Yes, that would be a loss for test readability. Also, I wouldn't be surprised
> if some test will want to attach POINT-B while POINT-A is in injection_wait().
Not impossible, still annoying with more complex scenarios.
> Various options avoiding those limitations:
>
> 1. The data area formerly called a "status" area is immutable after attach.
> The core code copies it into a stack buffer to pass in a const callback
> argument.
>
> 3. Move the PID check into core code.
The PID checks are specific to the module, and there could be much
more conditions like running only in specific backend types (first
example coming into mind), so I want to avoid that kind of knowledge
in the backend.
> (1) is, I think, simple and sufficient. How about that?
That sounds fine to do that at the end.. I'm not sure how large this
chunk area added to each InjectionPointEntry should be, though. 128B
stored in each InjectionPointEntry would be more than enough I guess?
Or more like 1024? The in-core module does not need much currently,
but larger is likely better for pluggability.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2024-05-09 04:52:14 | Re: First draft of PG 17 release notes |
Previous Message | Muhammad Ikram | 2024-05-09 04:47:34 | Re: First draft of PG 17 release notes |