Re: [HACKERS] pg_upgrade may be mortally wounded - Mailing list pgsql-hackers

> 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@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