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