Skip site navigation (1) Skip section navigation (2)

Re: Automatically ROLLBACK after fall in *ABORT STATE*

From: hstenger(at)adinet(dot)com(dot)uy
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Automatically ROLLBACK after fall in *ABORT STATE*
Date: 2000-07-28 20:14:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
hstenger(at)adinet(dot)com(dot)uy wrote:
> We all know PostgreSQL inability to handle exceptions. Inside a transaction, any
> error will make it fall in *ABORT STATE*, and any further action not being
> ROLLBACK, ABORT or COMMIT, will ask for a ROLLBACK, ABORT or COMMIT statement. I
> want to know what exact code is executed inside PostgreSQL, when a ROLLBACK
> statement is issued. Knowing that, I will modify backend/tcop/postgres.c, to do
> the necesary calls to ROLLBACK, inmediately after AbortCurrentTransaction().
> This will make PostgreSQL behave at least just like IBM's DB2, which rolls back
> automatically after an error.

I'm new to gdb.

I compiled PostgreSQL --enable-debug, and installed it.
Logged in as postgres superuser.
Ran postmaster -i as foreground.
Opened a second shell.
Opened ddd-gdb debugger.
Opened postmaster binary with symbols.
Opened a third shell.
Run psql template1. This makes the postmaster fork.
>From the gdb, attach to the forked postmaster, the one attending the psql
connection, and start it.

Now I run commands from psql, and expect the debugger to follow the backend
resolution of my queries. But nothing moves.

I want to see what happens in the backend when I enter ROLLBACK in psql.

Please, help me.


 Haroldo Stenger      | hstenger(at)ieee(dot)org
 Montevideo, Uruguay. | hstenger(at)adinet(dot)com(dot)uy
 Visit UYLUG Web Site:

In response to

pgsql-hackers by date

Next:From: Malcolm BeattieDate: 2000-07-28 20:53:34
Subject: Re: Security choices...
Previous:From: Henry B. HotzDate: 2000-07-28 18:39:27
Subject: Re: mac.c

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group