On L, 2005-07-09 at 09:47 -0400, Mike Mascari wrote:
> Stephen Frost wrote:
>
> > delete from x;/truncate x;
> > --> Creates a new, empty, file and makes it the 'current' file
> > --> Marks the old file for deletion, but it is kept around for any
> > transactions which were started before the truncate;
> > --> New transactions use the empty file
> > --> Once all transactions using the old file have completed, the old
> > file can be deleted.
> > --> Old transactions which insert rows would need to use the new file
> > or scan the old file for rows which they added, I suppose.
>
> And when the transaction that issued the TRUNCATE aborts after step 3,
> but newer transactions commit?
should be the same as when newer transactions had used a file after a
DELETE ; had been issued.
Could the new file not be made to cover the next available 1GB of file
space, that is a new physical file ?
This could made using of same kind of machinery my proposal for
concurrent index does (i.e. locks that forbid putting new tuples in
certain tuple ranges)
Then, if the truncating transaction commits, the N first pgysical 1GB
files are removed, and just the remaining ones are used. if it aborts,
the first files stay, and we just have some tuples placed sparcely
starting at the next 1GB boundary.
--
Hannu Krosing <hannu@skype.net>
