Re: Ultimate DB Server

Hannu Krosing <hannu@tm.ee>

From: Hannu Krosing <hannu@tm.ee>
To: Mike Rogers <temp6453@hotmail.com>
Cc: Christopher Kings-Lynne <chriskl@familyhealth.com.au>, pgsql-hackers@postgresql.org, Jean-Michel POURE <jm.poure@freesurf.fr>
Date: 2001-10-29T07:44:39Z
Lists: pgsql-hackers, pgsql-general
Mike Rogers wrote:
> 
> What that does is very simple: it rolls back the one that is keeping track
> of it's transactions.  Think of the overhead if someone doesn't have
> transactional statements.  The idea is, in PGSQL, all inserts and updates
> are essentially logged so that they can be rolled back.  Here is the MySQL
> concept:
>     Have a log table that logs all transactions (lets say, failed or not)
>         1.    begin transaction
>         2.    insert into non-transactional table 'user did this,
>               status - unprocessed'
>         3.    insert into payment table
>         4.    insert into product table
>         5.    update to processed
>         6.    insert into shipping
>         7.    update to 'pending shipping'
>   Perfectly common transaction that happens.  Now!  What if you want the
> entry inserted and dealt with as a status and what happens, but you don't
> want all the evidence of that to disappear when you hit rollback. 
> It means you can have some things roll back and others don't.  In PGSQL,
> that would have to be begin/rollback for only transactional entries.

Or you would run two parallel transactions (currently you need two
connections 
for this) - one for logging and one for work.

I agree that having non_transactional (i.e. logging) tables may be
sometimes 
desirable. I've been told that some of Oracles debugging/logging
facilities 
are almost useless due-to the fact that they disappear at rollback.

------------------
Hannu