Re: Problems Vacuum'ing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problems Vacuum'ing
Date
Msg-id 11116.1080962479@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problems Vacuum'ing  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> But, if I read the code correctly, the oldest xmin vacuum cares about
> for a non-shared relation should be local to the database, shouldn't it?

It's the oldest xmin of any transaction that's local to your database,
but those xmin values themselves were computed globally --- so what
matters is the oldest transaction that was running when any local
transaction started.  In this case I expect it's the VACUUM's own
transaction that's seeing the other guy as determining its xmin.

We could fix this by making every transaction compute, and advertise in
the PGPROC array, both local and global xmin values.  In previous
iterations of this discussion we concluded that the extra cycles (which
would be spent in *every* transaction start) could not be justified by
making VACUUM better able to reclaim space in the face of misbehaving
clients.  That conclusion might be wrong, but it's not instantly obvious
that it is...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Better support for whole-row operations and composite types
Next
From: Tom Lane
Date:
Subject: Re: Function to kill backend