RE: [HACKERS] Happy column dropping

> -----Original Message-----
> From: Peter Eisentraut [mailto:peter(at)sd(dot)tpf(dot)co(dot)jp]On Behalf Of Peter
> Eisentraut
>
> On 2000-01-23, Hiroshi Inoue mentioned:
>
> > Anyway I have 2 basic questions.
> >
> > 1) Is the * 2x disk usage * implementation really needed ?
>
> Yes, unless you bypass all transaction logic and do a get a row, change
> the row, delete the old row, write the new row, and silently hope that no
> problems come up down the line. If you do an SQL update of all the rows in
> a 10GB table you temporarily need 20GB in case there is a rollback.
>

I have already proposed another idea.
It only changes pg_attribute not touching relation files at all.
Probably it isn't the best solution but would be better than 2x disk usage
implementation.

> > 2) Why rename() ?
> > I don't trust rename() at all in transaction control.
> > The first thing we should do it to change relname -> relation file
> > name mapping in order to avoid calling rename().
>
> That's a good point. The alter table / rename code makes free use of this,
> which is just waiting to kick somebody in the head. If you think this
> could be addressed in the next release, I'm even for dropping my
> business and wait for a cleaner solution.
>

I wonder that no one but me has complained about this.
CLUSTER/ALTER TABLE RENAME TO already have the same flaw.
And maybe restructuring VACUUM also.
As far as I see,fixed mapping relname to relation filename is the
problem. This doesn't allow the coexistence of old and new relation
files. If old and new relation files could coexist we would be able to
update the relation_file_name attribute(we should add this kind of
atribute) of pg_class. Of cource,there must be the standard
mechanism to remove old files after commit.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp