Re: Ultimate DB Server
От | Hannu Krosing |
---|---|
Тема | Re: Ultimate DB Server |
Дата | |
Msg-id | 3BDD08E7.360984F8@tm.ee обсуждение исходный текст |
Ответ на | Re: Ultimate DB Server ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Список | 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
В списке pgsql-hackers по дате отправления: