On Mon, May 18, 2015 at 6:44 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
