On E, 2005-04-25 at 11:11 -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > On Sun, Apr 24, 2005 at 12:02:37PM +0300, Hannu Krosing wrote: > >> Must some locks also be released an reaquired inside this loop, or is > >> there something else I should keep in mind when trying to do this ? > > > There is "session lock" on the table. You must release that. > > Actually, the only hope of making this work is NOT to release that. > If you hold the appropriate lock at the session level then it is > reasonable to consider successive transactions within the vacuum > as being one big operation. > > I think the major issue with this would be memory management, ie, > how to prevent CommitTransactionCommand from cleaning up all of > vacuum's working state.
Are there any known (easy :) tricks for achieving this ? Now that I have had time to look a little more at this I have another idea: Could I avoid having a transaction at all? As VACUUM is not "transactional" in the sense that it does not change anything visible to users ever, can't be undone by rollback, etc... , could it be possible to create enough "transaction-like" environment for it to really run outside of transactions. Perhaps just advancing oldestXmin at certain intervals ? -- Hannu Krosing <[EMAIL PROTECTED]> ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])