> Alvaro Herrera wrote: > >Joseph S wrote: > >>I realize this thread is old, but I just conducted an experiment with pg > >>8.0.10 and a transaction with a SERIALIZABLE isolation level does > >>prevent VACUUM from reclaiming rows that were created and then obsoleted > >> in a subsequent transaction. > > > >Right. This is expected. VACUUM cannot remove them because the > >serializable transaction might still want to see those rows. (I am > >assuming the serializable transaction is still running when the vacuum > >starts. If that's not the case, please explain better). Joseph S wrote: > The serializable transaction *can't* see those rows, they were created > and obsoleted after the start of the transaction. The point of make the > transaction serializable in the first place was to allow VACUUM to > reclaim those rows. Well, if you're thinking that vacuum will reclaim those rows just because the transaction is serializable and thus the rows are invisible, you're mistaken. If that's the only reason to set the transaction serializable, you'll be better off changing it to read committed because you're not getting that benefit. It's possible that there's some optimization to be made here, but right now it doesn't exist. (And to be frank, I haven't thought about the issue to be certain that the optimization is possible at all -- maybe there's some reason why it's not, for example ctid chains or whatever). -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
