Making the regression tests halt to attach a debugger
От | Peter Geoghegan |
---|---|
Тема | Making the regression tests halt to attach a debugger |
Дата | |
Msg-id | CAM3SWZRJZ2OWEUP2Mxt+s_N7q8RrzvUyQJkwspEYxy61mpjXdg@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Making the regression tests halt to attach a debugger
|
Список | pgsql-hackers |
During the course of UPSERT's development, I found it tricky to debug regression tests failures on occasion. There are often non-obvious dependencies across and within regression tests. Creating a minimal test case having attached a debugger to a directly controlled backend is often tricky, or at least time consuming. I came up with a simple approach to conveniently attaching a debugger when a bug manifested itself from within the regression tests, by patching Postgres. This worked quite well. The backend would look for the occurrence of a magical token within each and every query string. pg_analyze_and_rewrite() had a simple additional check for this magical token. pg_analyze_and_rewrite() seemed like a suitably early point in the query execution cycle, while still being late enough after the main tcop loop to be a general purpose chokepoint (maybe there's a better, earlier general purpose chokepoint that makes debugging raw parsing possible, for example, but I didn't need to do that). I'd add a C-style comment to any regression suite SQL query that failed, naming just the magical token (something like: /* pg-halt-for-debugger */ ). Just before the query underwent parse analysis, if the comment/token was detected, the backend would advertise that I should attach to its PID using GDB, and then "raise(SIGSTOP)" so I'd have time to do so. I'd then actually attach GDB, set a breakpoint somewhere interesting (and relevant to the failure) from within GDB, and continue. It occurred to me that other hackers have probably done things like this. It seems like it might be worthwhile to submit a patch that made it possible to do this in a standardized way. Obviously this is something that would only exist to be enabled on a developer's debug build, comparable to things like COPY_PARSE_PLAN_TREES. Is there any appetite for this? If there is a more polished way to get the regression tests to stop like this at some particular query, I'm not aware of it. In any case, I'm making the backend halt due to finding something in a query string, which ISTM needs backend support to work well. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: