Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Hannu Krossing asked me about his patch to ignore transactions running > > VACUUM LAZY in other vacuum transactions. I attach a version of the > > patch updated to the current sources. > > nonInVacuumXmin seems useless ... perhaps a vestige of some earlier > version of the computation?
Hmm, not useless at all really -- only a bug of mine. Turns out the notInVacuumXmin stuff is essential, so I put it back. I noticed something however -- in calculating the OldestXmin we always consider all DBs, even though there is a parameter for skipping backends not in the current DB -- this is because the Xmin we store in PGPROC is always computed using all backends. The allDbs parameter only allows us to skip the Xid of a transaction running elsewhere, but this is not very helpful because the Xmin of transactions running in the local DB will include those foreign Xids. In case I'm not explaining myself, the problem is that if I open a transaction in database A and then vacuum a table in database B, those tuples deleted after the transaction in database A started cannot be removed. To solve this problem, one idea is to change the new member of PGPROC to "current database's not in vacuum Xmin", which is the minimum of Xmins of backends running in my database which are not executing a lazy vacuum. This can be used to vacuum non-shared relations. We could either add it anew, beside nonInVacuumXmin, or replace nonInVacuumXmin. The difference will be whether we will have something to be used to vacuum shared relations or not. I think in general, shared relations are not vacuumed much so it shouldn't be too much of a problem if we leave them to be vacuumed with the regular, all-databases, include-vacuum Xmin. The other POV is that we don't really care about long-running transaction in other databases unless they are lazy vacuum, a case which is appropiately covered by the patch as it currently stands. This seems to be the POV that Hannu takes: the only long-running transactions he cares about are lazy vacuums. Thoughts? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
