Re: tuple concurrently updated

Поиск
Список
Период
Сортировка
От Mike Mascari
Тема Re: tuple concurrently updated
Дата
Msg-id 3D4066F0.EB15505F@mascari.com
обсуждение исходный текст
Ответ на Re: tuple concurrently updated  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
"Kangmo, Kim" wrote:
> 
> How do you think about my suggestion to not versioning system catalogs?
> 
> p.s. It's unbelivable that I got a reply from legendary Tom Lane. :)
> 
> Best,
> Kim.

I can guess what Tom's going to say, since I argued your position
approx. 3 years ago. Implicitly committing transactions would not allow
for rollback of DDL statements. This is a great feature that PostgreSQL
has striven for that Oracle lacks. 3 years ago, it seemed to be a
problem, when a table created in an aborted transaction was not being
correctly cleaned up. It gets in the way of implementing an ALTER TABLE
DROP COLUMN easily, since rollback of a dropped column means that the
underlying data must be preserved. However, the developers have made
such great progress in properly rolling back DDL statements that it
would be a real shame to lose such a great feature. Additionally, it
could seriously break a lot of applications out there that do not
expect:

INSERT INTO foo VALUES (1);
CREATE TABLE bar (key integer);
ROLLBACK;

to fail to rollback the INSERT into foo. When the original discussion
came up, there were even a few of Oracle developers that didn't know
Oracle was committing their transactions behind their back.

Mike Mascari
mascarm@mascari.com


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

Предыдущее
От: nconway@klamath.dyndns.org (Neil Conway)
Дата:
Сообщение: Re: [PATCHES] prepareable statements
Следующее
От: Marc Lavergne
Дата:
Сообщение: Re: CREATE SYNONYM suggestions