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

From Jim Nasby
Subject Re: Making the regression tests halt to attach a debugger
Date
Msg-id 555A09DD.7060007@BlueTreble.com
Whole thread Raw
In response to Re: Making the regression tests halt to attach a debugger  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Making the regression tests halt to attach a debugger  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 5/18/15 8:44 AM, Tom Lane 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.
>
> A variant is to insert a sleep() in the C code, in someplace you don't
> expect will be reached except in the problematic cases.

You still have to hunt down the PID though; it's nicer if you just get 
it spit out in the log or to the client. This would also make it easier 
to debug interactive backends since you could just embed the magic 
comment in your test statement instead of needing a separate call to 
pg_backend_pid().
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Next
From: Andrew Dunstan
Date:
Subject: Re: Disabling trust/ident authentication configure option