Re: different transaction handling between postgresql and

Поиск
Список
Период
Сортировка
От Mike Mascari
Тема Re: different transaction handling between postgresql and
Дата
Msg-id 3F127578.3090606@mascari.com
обсуждение исходный текст
Ответ на Re: different transaction handling between postgresql and  (Peter Childs <blue.dragon@blueyonder.co.uk>)
Ответы Re: different transaction handling between postgresql and  ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>)
Список pgsql-general
Peter Childs wrote:

> On Mon, 14 Jul 2003, Mike Mascari wrote:
>
>>Jörg Schulz wrote:
>>
>>Presumably Oracle is not rolling back a duplicate key violation,
>>allowing the transaction to continue. This is an often requested
>>feature not present in PostgreSQL.
>
>
> Bug. Not Feature
>
>     Transactions must be all or nothing. If one step fails for what
> ever reason all steps must be failed and rolled back. While in this simple
> case ignoring the statment may look fine in more complex examples (where
> the is more data in the table...) this can mean data loss and massive
> problems!

I agree. However a common scenario that has appeared on these lists is
a request for an atomic 'CREATE IF NOT EXISTS, ELSE REPLACE' without
race conditions. Because Oracle doesn't rollback the transaction, it
is implementable in SQL. For PostgreSQL, you either need to use
various locking techniques which reduces concurrency or be prepared to
resubmit the entire transaction. Savepoints and/or nested transactions
may alleviate the situation in the future, however.

Mike Mascari
mascarm@mascari.com



В списке pgsql-general по дате отправления:

Предыдущее
От: Csaba Nagy
Дата:
Сообщение: Re: different transaction handling between postgresql and
Следующее
От: "Shridhar Daithankar"
Дата:
Сообщение: Re: different transaction handling between postgresql and