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

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.


Alvaro Herrera                      
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

Reply via email to