Re: vacuum does not reclaim rows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: vacuum does not reclaim rows
Date
Msg-id 6976.1057456276@sss.pgh.pa.us
Whole thread Raw
In response to vacuum does not reclaim rows  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: vacuum does not reclaim rows  (Andrew Sullivan <andrew@libertyrms.info>)
Re: vacuum does not reclaim rows  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: elein
Date:
Subject: Re: [GENERAL] Are we backwards on the sign of timezones?
Next
From: "Mendola Gaetano"
Date:
Subject: Re: PostgreSQL 7.3.3 and Intel C compiler