Re: vacuum does not reclaim rows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: vacuum does not reclaim rows
Date: 2003-07-06 01:51:16
Message-ID: 6976.1057456276@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mendola Gaetano 2003-07-06 02:48:49 Re: PostgreSQL 7.3.3 and Intel C compiler
Previous Message Hannu Krosing 2003-07-06 00:11:58 Re: PostgreSQL vs. MySQL