Re: Ultimate DB Server

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Mike Rogers <temp6453(at)hotmail(dot)com>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org, Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr>
Subject: Re: Ultimate DB Server
Date: 2001-10-29 07:44:39
Message-ID: 3BDD08E7.360984F8@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-general pgsql-hackers

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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Jean-Michel POURE 2001-10-29 07:50:36 Re: Ultimate DB Server
Previous Message leo 2001-10-29 05:51:08 dump large object

Browse pgsql-general by date

  From Date Subject
Next Message Ren Weili 2001-10-29 07:45:05 resend: Chinese sort order problem
Previous Message Tatsuo Ishii 2001-10-29 05:43:55 Re: Broken pipes 2

Browse pgsql-hackers by date

  From Date Subject
Next Message Jean-Michel POURE 2001-10-29 07:50:36 Re: Ultimate DB Server
Previous Message Hannu Krosing 2001-10-29 07:32:46 Re: [HACKERS] What about CREATE OR REPLACE FUNCTION?