Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Дата
Msg-id CAMsr+YEnhYbM-eiryFrBhqbyyMcM=BZBrEHMD5mTYLjxVcZw+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers


On 21 June 2016 at 20:19, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jun 20, 2016 at 10:08 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May 20, 2016 at 07:40:53PM -0400, Robert Haas wrote:
>> On Mon, May 16, 2016 at 3:36 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> > On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote:
>> >> 2) There's no ability at all to revert, other than restore a backup. That
>> >> means if you pull the trigger and discover some major performance problem,
>> >> you have no choice but to deal with it (you can't switch back to the old
>> >> version without losing data).
>> >
>> > In --link mode only
>>
>> No, not really.  Once you let write transactions into the new cluster,
>> there's no way to get back to the old server version no matter which
>> option you used.
>
> Yes, there is, and it is documented:
>
>         If you ran <command>pg_upgrade</command> <emphasis>without</>
>         <option>--link</> or did not start the new server, the
>         old cluster was not modified except that, if linking
>         started, a <literal>.old</> suffix was appended to
>         <filename>$PGDATA/global/pg_control</>.  To reuse the old
>         cluster, possibly remove the <filename>.old</> suffix from
>         <filename>$PGDATA/global/pg_control</>; you can then restart the
>         old cluster.
>
> What is confusing you?

I don't think I'm confused.  Sure, you can do that, but the effects of
any writes performed on the new cluster will not be there when you
revert back to the old cluster.  So you will have effectively lost
data, unless you somehow have the ability to re-apply all of those
write transactions somehow.

Also, if you run *with* --link, IIRC there's no guarantee that the old version will be happy to see any new infomask bits etc introduced by the new Pg. I think there will also be issues with oid to relfilenode mappings in pg_class if the new cluster did any VACUUM FULLs or anything. It seems likely to be a bit risky to fall back on the old cluster once you've upgraded with --link . TBH it never even occurred to me that it'd be possible at all until you mentioned.

I always thought of pg_upgrade as a one-way no-going-back process either way, really. Either due to a fork in history (without --link) or due to possibly incompatible datadir changes (with --link).

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: Postgres_fdw join pushdown - wrong results with whole-row reference
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Missing checks when malloc returns NULL...