Re: vacuum does not reclaim rows

I think the big issue is that people think that if they have no one in a
specific database, that VACUUM FULL will completely remove unused
space, while this is not true if there are other backends connected to
other databases.

This might be a stupid question, but why does one backend have to care
about the global xmin at all? Isn't the local xmin the only important
value?

---------------------------------------------------------------------------

Tom Lane wrote:
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > but after that it checks proc->xmin, where xmin may not be running on
> > the same database. I wonder if this is correct or not. Maybe we should
> > make sure that xmin is running on the same database
>
> How would you know? (At the time you are looking, it's quite possible
> the other guy's xmin doesn't exist anymore.) In any case you can't just
> arbitrarily ignore the other guy's xmin, since it's a proxy for
> subsequent transaction IDs as well, and those might be in any database.
>
> It might be possible to do something by having each proc store both
> a "local" and a "global" xmin computed as of its current xid start,
> but I haven't really thought through the details. In any case, that
> would be extra bookkeeping needed during every transaction start,
> so I'd want to see proof of a generally-useful improvement in return.
>
> On the whole I'm against changing this logic ... I think the odds
> of breaking something are high, and the odds of making a useful
> improvement low ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073