On Mon, May 18, 2015 at 6:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <pg@heroku.com> writes:
>> 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.
>
> If your approach involves modifying a target query in a regression test,
> it really seems unnecessary to do all this. Just insert something like
> "select pg_sleep(60)" into the test script before the target query.
That seems less convenient, because I have to wait for the backend to
wake up within GDB.
I use a script that attaches GDB to an inferred-from-ps Postgres
backend, too. But it's possible to imagine that not working that well.
Like with an isolation test, for example. I like that the backend
advertises that I should connect GDB to its PID, and will wait all day
as necessary.
I also wrote a script that infers a useful non-auxiliary backend PID
(in the same way as the other GDB script), but just sends it SIGCONT.
I could then continue the test in a convenient way without attaching a
debugger.
Anyway, it was just an idea. If people aren't sold on the merits of
making this into development infrastructure, I'll leave it at that.
--
Peter Geoghegan