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

On Tue, Jun 21, 2016 at 11:34 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Tue, Jun 21, 2016 at 08:19:55AM -0400, Robert Haas wrote:
>> On Mon, Jun 20, 2016 at 10:08 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> >> 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.
>
> Yes, that is true. I assume _revert_ means something really bad
> happened and you don't want those writes because they are somehow
> corrupt.

I think that it's pretty likely you could, say, upgrade to a new major
release, discover that it has a performance problem or some other bug
that causes a problem for you, and want to go back to the older
release. There's not really an easy way to do that, because a pg_dump
taken from the new system might not restore on the older one. Logical
replication - e.g. Slony - can provide a way, but we don't have
anything in core that can do it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company