From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Making the regression tests halt to attach a debugger |
Date: | 2015-05-18 15:48:45 |
Message-ID: | 555A09DD.7060007@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/18/15 8:44 AM, Tom Lane wrote:
> Peter Geoghegan <pg(at)heroku(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2015-05-18 15:50:16 | Re: Disabling trust/ident authentication configure option |
Previous Message | Bruce Momjian | 2015-05-18 15:41:32 | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION |