From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Palle Girgensohn <girgen(at)partitur(dot)se>, Patrik Kudo <kudo(at)partitur(dot)se>, "pgsql-sql(at)postgreSQL(dot)org" <pgsql-sql(at)postgreSQL(dot)org> |
Subject: | Re: [SQL] Duplicate tuples with unique index |
Date: | 2000-01-26 05:43:22 |
Message-ID: | 200001260543.AAA22584@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> Bruce thinks that the pg_upgrade script will ensure that the system-
> table tuples are all in frozen states (by VACUUMing them). I don't
> trust it worth a dime, myself. Maybe it will work, but it hasn't been
> proven in the field. So, if you'd like to try it, by all means do so
> --- but make a pg_dump backup first! And let us know whether you have
> problems or not!
I see what you are saying. If a table created as part of the new
pg_dump schema create matches a transaction that aborted in the old
database, the table would be invalid. However, as you mentioned, once
the tuple is marked as committed/rolled back, it doesn't consult.
Basically, I was surprised pg_upgrade worked at all in any of the
releases. It seems too good to be true. However, I have received very
few problem reports about its use, and it does get used.
--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Kovacs Zoltan Sandor | 2000-01-26 10:57:17 | dumping groups and users |
Previous Message | Tom Lane | 2000-01-26 05:38:43 | Re: [SQL] Duplicate tuples with unique index |