Re: tuple concurrently updated - Mailing list pgsql-hackers

From Mike Mascari
Subject Re: tuple concurrently updated
Date
Msg-id 3D4066F0.EB15505F@mascari.com
Whole thread Raw
In response to Re: tuple concurrently updated  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: nconway@klamath.dyndns.org (Neil Conway)
Date:
Subject: Re: [PATCHES] prepareable statements
Next
From: Marc Lavergne
Date:
Subject: Re: CREATE SYNONYM suggestions