Re: Better Upgrades - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Better Upgrades
Date
Msg-id 20180302000300.GA30743@momjian.us
Whole thread Raw
In response to Re: Better Upgrades  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Better Upgrades  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
On Tue, Feb  6, 2018 at 01:51:09PM +0100, Daniel Gustafsson wrote:
> > On 06 Feb 2018, at 01:09, David Fetter <david@fetter.org> wrote:
> 
> > - pg_upgrade is very much a blocker for on-disk format changes.
> 
> I wouldn’t call it a blocker, but pg_upgrade across an on-disk format change
> would be a very different experience from what we have today since it would
> need to read and rewrite data rather than hardlink/copy.  Definitely not a
> trivial change though, that I completely agree with.

Uh, not necessarily.  To allow for on-disk format changes, pg_upgrade
_could_ rewrite the data files as it copies them (not link), or we could
modify the backend to be able to read the old format.  We have already
done that for some changes to data and index types.

If we did add more backward-read capability to the backend, I think we
would need to add some housekeeping so we could know when the
read-old-format code could be removed.

I have to admit that the number of hurdles needed to use logical
replication to reduce downtime made me feel like it is cleaner to just
take the multi-minute downtime using link mode and have it be reliable. 
Even if you can get logical replication to work, the drain/switch over
time could be significant.

-- 
  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. +
+                      Ancient Roman grave inscription +


pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: [HACKERS] Bug in to_timestamp().
Next
From: David Steele
Date:
Subject: Re: Hash Joins vs. Bloom Filters / take 2