Обсуждение: Noob Hints on testing and debugging?

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.

James

James Mansion <james@mansionfamily.plus.com> 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

On Wed, Mar 12, 2008 at 7:21 AM, James Mansion
<james@mansionfamily.plus.com> 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

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