Ühel kenal päeval (teisipäev, 8. veebruar 2005, 13:39-0300), kirjutas
Alvaro Herrera:
On Tue, Feb 08, 2005 at 01:55:47PM +0200, Hannu Krosing wrote:
So I guess that making it commit and open new transaction at a regular
interval (like each minute) during vacuuming single table would not
Ühel kenal päeval (esmaspäev, 7. veebruar 2005, 19:01-0300), kirjutas
Alvaro Herrera:
Also, why must it be run outside of transaction block if it can be
rollbacked ?
A vacuum actually uses several transactions, so it wouldn't work as the
user would expect if run in a transaction. The
On Tue, Feb 08, 2005 at 01:55:47PM +0200, Hannu Krosing wrote:
So I guess that making it commit and open new transaction at a regular
interval (like each minute) during vacuuming single table would not
alter its visible behaviour. That would solve my problem of long-running
vacuums on large
Hi
As VACUUM is not something that can be rolled back, could we not make it
run completely outside transactions. It already needs to be run outside
a transaction block.
I try to explain the problem more thoroughly below (I'm quite sleepy, so
the explanation may be not too clear ;)
My problem
Hannu Krosing [EMAIL PROTECTED] writes:
As VACUUM is not something that can be rolled back, could we not make it
run completely outside transactions.
No, because it has to be able to hold a table-level lock on the target
table. Besides, where did you get the idea that it can't be rolled back?
Ühel kenal päeval (esmaspäev, 7. veebruar 2005, 10:51-0500), kirjutas
Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
As VACUUM is not something that can be rolled back, could we not make it
run completely outside transactions.
No, because it has to be able to hold a table-level lock on
On Mon, Feb 07, 2005 at 07:16:41PM +0200, Hannu Krosing wrote:
If all the changes it does to internal data storage can be rolled back,
then I can't see how VACUUM FULL can work at all without requiring 2x
the filesize for the ROLLBACK.
I think the point is that the table is still consistent
