Re: Problems Vacuum'ing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Problems Vacuum'ing
Date: 2004-04-03 03:21:19
Message-ID: 11116.1080962479@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-04-03 03:55:21 Re: Function to kill backend
Previous Message Tom Lane 2004-04-03 03:13:15 Re: Better support for whole-row operations and composite types