Re: [HACKERS] pg_upgrade may be mortally wounded

> BTW, it seems to me that it is a good idea to kill and restart the
> postmaster immediately after pg_upgrade finishes. Otherwise there might
> be buffers in shared memory that do not reflect the actual contents of
> the corresponding pages of the relation files (now that pg_upgrade
> overwrote the files with other data).

Honestly, I have been surprised at how well pg_upgrade worked in 6.4. I
got very few complaints, and I think people used it.

Your issue with buffer cache is a major one. Clearly, this would be a
problem. However, it is my understanding that the buffer cache after
initdb would only contain system table info, so if they pg_upgrade after
that, there is no way they have bad stuf in the cache, right?

>
> Another potential gotcha is that it'd be a really bad idea to let any
> other clients connect to the new database while it's being built.

That is pretty obvious, and just basic sysadmin.

>
> Looking at these two items together, it seems like the really safe way
> for pg_upgrade to operate would be *not* to start a postmaster for the
> new database until after pg_upgrade finishes; that is, the procedure
> would be "initdb; pg_upgrade; start postmaster". pg_upgrade would
> operate by invoking a standalone backend for initial table creation.
> This would guarantee no unwanted interference from other clients
> during the critical steps.
>
> The tricky part is that pg_dump output includes psql \connect commands,
> which AFAIK are not accepted by a standalone backend. We'd have to
> figure out another solution for those. Ideas?
>
> regards, tom lane
>
> PS: if you try to test pg_upgrade by running the regression database
> through it, and then "vacuum analyze" the result, you will observe a
> backend crash when vacuum gets to the table "c_star". This seems to be
> the fault of a bug that Chris Bitmead has complained of in the past.
> c_star has had a column added via inherited ALTER TABLE ADD COLUMN, and
> the output of pg_dump creates a database with a different column order
> for such a table than ADD COLUMN does. So, the reconstructed database
> schema does not match the table data that pg_upgrade has moved in. Ugh.
> But we already knew that inherited ADD COLUMN is pretty bogus. I wonder
> whether we shouldn't just disable it until it can be fixed properly...
>

And report a message to the user. Good idea.

--
Bruce Momjian | http://www.op.net/~candle
maillist(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