Re: Making the regression tests halt to attach a debugger
От | Peter Geoghegan |
---|---|
Тема | Re: Making the regression tests halt to attach a debugger |
Дата | |
Msg-id | CAM3SWZRjjBPCxY-5v6nRR1h7Q5aSK9CfUqf59dQ7MBEt0tfXZg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Making the regression tests halt to attach a debugger (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: