Hannu Krosing <hannu@skype.net> writes:
> When I asked the same question, I was told that a lot of core
> functionality vacuum uses needs to be in transaction. I guess bad things
> can happen, if some other backend ends a transaction you claim to be in.
>
> And it is not so much about what ends up in tables, but about what other
> backends think.
Well the only way other backends would find out about vacuum's xid is via
tables or via the PGProc table. But they aren't going to care about vacuum's
transaction status in PGProc unless they're vacuum and then we're going out of
our way to make sure it doesn't care.
Vacuum doesn't take any record locks so the xid isn't necessary for that.
Vacuum does WAL log some entries via log_heap_clean but I'm unclear whether
that requires a transaction, I don't see it being used anywhere.
> BTW, I think that CONCURRENT CREATE INDEX should be modified to use long
> transactions which actually build the index and are ignored by vacuum
> and short ones which write data to system tables and are not ignored.
> That way we have one less obstacle for keeping high-update tables in
> shape.
Hm, that might be worth thinking about. Note that it locks out vacuum from
running on the table it's running on so it would only help in allowing other
tables to be vacuumed effectively. If we ever get per-table xmin then it would
be entirely unnecessary.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com