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

From Peter Geoghegan
Subject Re: Making the regression tests halt to attach a debugger
Date
Msg-id CAM3SWZRjjBPCxY-5v6nRR1h7Q5aSK9CfUqf59dQ7MBEt0tfXZg@mail.gmail.com
Whole thread Raw
In response to Re: Making the regression tests halt to attach a debugger  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: How does MSVC's fetchRegressOpts() work at all?
Next
From: Andrew Dunstan
Date:
Subject: Re: jsonb concatenate operator's semantics seem questionable