Re: [HACKERS] PG_UPGRADE status

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] PG_UPGRADE status
Дата
Msg-id 199909090307.XAA03261@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] PG_UPGRADE status  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> pg_upgrade *does* overwrite the destination pg_log, and what that
> means is that incoming tuples in user relations should be fine.
> What's at risk is recently-committed tuples in the system relations,
> notably the metadata that pg_upgrade has just inserted for those
> user relations.
> 
> The point of the VACUUM is to try to ensure that everything
> in the system relations is marked as certainly committed (or
> certainly dead) before we discard the pg_log information.
> I don't recall ever hearing from Vadim about whether that
> is a trustworthy way of doing it, however.
> 
> One thing that occurs to me just now is that we probably need
> to vacuum *each* database in the new installation.  The patch
> I added to pg_dump doesn't do the job because it only vacuums
> whichever database was dumped last by pg_dumpall...

I see what you are saying now.  pg_upgrade basically replaces the system
tables, but keeps the user data and pg_log.  So, if you do initdb, and
create your user table, then recover the user data tables and pg_log,
and if pg_log has a transaction marked as aborted that has the same
number as one of the user create table statements, it would not see the
table.  I see why the vacuum is needed.

I wrote pg_upgrade as an attempt to do upgrades without dumping.  I
heard so little about it when it was introduced, I thought it was not
really being used.  When I disabled it for 6.5, I found out how many
people were using it without incident.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


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

Предыдущее
От: "Damond Walker"
Дата:
Сообщение: Sparc stuff again.
Следующее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] Problem enabling pltcl