Re: pg_upgrade bug found!

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_upgrade bug found!
Дата
Msg-id 201104091059.p39AxcK26471@momjian.us
обсуждение исходный текст
Ответ на Re: pg_upgrade bug found!  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: pg_upgrade bug found!  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Alvaro Herrera wrote:
> 
> Why is it important to have the original pg_clog files around?  Since
> the transactions in question are below the freeze horizon, surely the
> tuples that involve those transaction have all been visited by vacuum
> and thus removed if they were leftover from aborted transactions or
> deleted, no?  So you could just fill those files with the 0x55 pattern
> (signalling "all transactions are committed") and the net result should
> be the same.  No?
> 
> Forgive me if I'm missing something.  I haven't been following this
> thread and I'm more than a little tired (but wanted to shoot this today
> because I'm gonna be able to, until Monday).

Well, in most cases vacuum (or SELECT?) is going to set those xids as
committed on the tuple, but if there have been few deletes in the toast
table, it is possible vacuum did not run.  I think the fact we only have
three report query error cases is because in most cases vacuum is
already taking care of this as part of space reuse.

relfrozenxid is not going to cause freeze to run and therefore those
xids, even though marked as committed, still are on the tuple, so we
need this script to be run.

In fact, if the tuple is marked as committed, do we even bother to mark
the xids as fixed via vacuum freeze?  Seems we don't have to.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade bug found!
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pgindent