Re: [HACKERS] Noob Hints on testing and debugging?
Tom Lane wrote: (eg how to run it up and feed it SQL ideally without running a postmaster and execing a back end) Why would you consider that ideal? Such a scenario would have approximately zip to do with the real-world environment your patch would face. Your points what? If I'm fiddling with the language parser and transaction engine, that's hardly relevant. Its necessary to debug in a full env too, of course, but an ability to run a standalone engine which does its own private shmem setup would be handy. If its not there, too bad. It makes the compile/test cycle much faster, since you don't have to go through the rigmarole of attaching to a process, and its one of the aspects of using VS that's a whole pile nicer than the make/start/gdb-to-process stuff I have to use at work. (And at least I have TotalView there, even if the admins can't organise KDevelop or Anjuta or Eclipse.) Is there any sanity at all in a trigger-on-rollback? Exactly what would you expect it to be able to accomplish that anyone else could see after the transaction has rolled back? (And no, trigger on commit isn't very much saner.) Why do you say this? I'm interested in side effects external to the db. Logging to a custom logger is an obvious trivial example - in fact I want to set flags in the data triggers and then process them. I'm currently thinking that rollback can be dispensed with in favour of a setup phase on commit start. I'm looking to do things that would otherwise be handled with the event system for some use cases but not all (eg a final consistency check point in before commit). Since that seems to have issues and this can be more general, it seems worth looking at. I'll post a straw man. James -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Noob Hints on testing and debugging?
James Mansion [EMAIL PROTECTED] writes: Are there any hints and tips anywhere on practical issues for testing and debugging changes to a backend? hackers-list archives has a thread or three... (eg how to run it up and feed it SQL ideally without running a postmaster and execing a back end) Why would you consider that ideal? Such a scenario would have approximately zip to do with the real-world environment your patch would face. What I usually do is fire up a normal psql session and then attach to the backend process with gdb in another window. The only cases where this isn't very useful is where you are trying to debug failure in very early session startup. There are some badly-documented options such as -W that can help even in that kind of situation. I'm using VS2008 on XP by choice, and I'd like to investigate supporting something closely related to the Firebird 2.1 trigger on transaction commmit and rollback. Is there any sanity at all in a trigger-on-rollback? Exactly what would you expect it to be able to accomplish that anyone else could see after the transaction has rolled back? (And no, trigger on commit isn't very much saner.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Noob Hints on testing and debugging?
On Wed, Mar 12, 2008 at 7:21 AM, James Mansion [EMAIL PROTECTED] wrote: Are there any hints and tips anywhere on practical issues for testing and debugging changes to a backend? (eg how to run it up and feed it SQL ideally without running a postmaster and execing a back end) I'm using VS2008 on XP by choice, and I'd like to investigate supporting something closely related to the Firebird 2.1 trigger on transaction commmit and rollback. I've yet to try 2008, but 2005 works beautifully when debugging the server - even stepping into non-core code is simple (I spent some time in the plpgsql debugger plugin for example). The hard part can be attaching the debugger to the appropriate backend. You can either introduce a startup delay (there's a backend command line option for that iirc), or if you want to break at a specific point, I sometimes add a loop to the code along the lines of: int x=0; while (!x) Sleep(100); When the backend hits that point, attach the debugger, break execution, and set x to a value in the locals window. Then you can step through the code from that point. -- Dave Page EnterpriseDB UK Ltd: http://www.enterprisedb.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
