Making the regression tests halt to attach a debugger - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Making the regression tests halt to attach a debugger
Date
Msg-id CAM3SWZRJZ2OWEUP2Mxt+s_N7q8RrzvUyQJkwspEYxy61mpjXdg@mail.gmail.com
Whole thread Raw
Responses Re: Making the regression tests halt to attach a debugger
List 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 by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension
Next
From: Denis Kirjanov
Date:
Subject: Re: trust authentication behavior