Re: Freeze avoidance of very large table.
От | Bruce Momjian |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | 20151223020656.GA674@momjian.us обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Thu, Dec 17, 2015 at 06:44:46AM +0000, Simon Riggs wrote: > >> Thank you for having a look. > > > > I would not bother mentioning this detail in the pg_upgrade manual page: > > > > + Since the format of visibility map has been changed in version 9.6, > > + <application>pg_upgrade</> creates and rewrite new <literal>'_vm'</ > literal> > > + file even if upgrading from 9.5 or before to 9.6 or later with link > mode (-k). > > Really? I know we don't always document things like this, but it > seems like a good idea to me that we do so. > > > Agreed. > > For me, rewriting the visibility map is a new data loss bug waiting to happen. > I am worried that the group is not taking seriously the potential for > catastrophe here. I think we can do it, but I think it needs these things > > * Clear notice that it is happening unconditionally and unavoidably > * Log files showing it has happened, action by action > * Very clear mechanism for resolving an incomplete or interrupted upgrade > process. Which VMs got upgraded? Which didn't? > * Ability to undo an upgrade attempt, somehow, ideally automatically by default > * Ability to restart a failed upgrade attempt without doing a "double upgrade", > i.e. ensure transformation is immutable Have you forgotten how pg_upgrade works? This new vm file is only created on the new cluster, which is not usable if pg_upgrade doesn't complete successfully. pg_upgrade never modifies the old cluster. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
В списке pgsql-hackers по дате отправления: