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