Re: vacuum does not reclaim rows

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: vacuum does not reclaim rows
Дата
Msg-id 6976.1057456276@sss.pgh.pa.us
обсуждение исходный текст
Ответ на vacuum does not reclaim rows  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Ответы Re: vacuum does not reclaim rows  (Andrew Sullivan <andrew@libertyrms.info>)
Re: vacuum does not reclaim rows  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: elein
Дата:
Сообщение: Re: [GENERAL] Are we backwards on the sign of timezones?
Следующее
От: "Mendola Gaetano"
Дата:
Сообщение: Re: PostgreSQL 7.3.3 and Intel C compiler