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@sra.co.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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073