Re: Must be owner to truncate?
От | Hannu Krosing |
---|---|
Тема | Re: Must be owner to truncate? |
Дата | |
Msg-id | 1120941832.4844.9.camel@fuji.krosing.net обсуждение исходный текст |
Ответ на | Re: Must be owner to truncate? (Mike Mascari <mascarm@mascari.com>) |
Ответы |
Re: Must be owner to truncate?
|
Список | pgsql-hackers |
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>
В списке pgsql-hackers по дате отправления: