Tom Lane <[EMAIL PROTECTED]> writes:
> > (3) When the XID count goes past the "trip wire" can it spontaneously
> > issue a vacuum?
>
> Only in the database you're connected to, which very likely isn't where
> the problem is. Moreover, having N backends all decide they need to do
> this at once doesn't sound like a winner. Furthermore, this still
> presumes the existence of the hard part of the solution, which is
> knowing where the trip point is.
Alright, I have a suggestion. If the database kept a "oldest xid" for each
table then there wouldn't be any expensive work to scan the table looking for
an oldest xid. The only time "oldest xid" needs to be updated is when vacuum
is run, which is precisely when it would be known.
There could be a per-database "oldest xid" that any vacuum on any table
updates (by skimming all the "oldest xid"s for the current database). If
that's stored in the shared pg_database table then it's accessible regardless
of what database you connect to, no?
Then on every connection and every n-thousandth transaction you just have to
check the "oldest xid" for all the databases, and make sure the difference
between the oldest one and the current xid is reasonable.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
