Re: PG Upgrade with hardlinks, when to start/stop master and replicas - Mailing list pgsql-general

From Bruce Momjian
Subject Re: PG Upgrade with hardlinks, when to start/stop master and replicas
Date
Msg-id 20190222023352.kcyomdb4w2l7n6px@momjian.us
Whole thread Raw
In response to Re: PG Upgrade with hardlinks, when to start/stop master and replicas  (Stephen Frost <sfrost@snowman.net>)
Responses Re: PG Upgrade with hardlinks, when to start/stop master and replicas  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Thu, Feb 21, 2019 at 09:31:32PM -0500, Stephen Frost wrote:
> Greetings,
> 
> * Bruce Momjian (bruce@momjian.us) wrote:
> > On Tue, Feb 19, 2019 at 12:25:24PM -0500, Stephen Frost wrote:
> > > Ah, right, I forgot that it did that, fair enough.
> > > 
> > > I've never been thrilled with that particular approach due to the
> > > inherent risks of people messing directly with files like pg_control,
> > > but that's how it is for now.
> > 
> > There was too much concern that users would accidentally start the old
> > server at some later point, and its files would be hard linked to the
> > new live server, leading to disaster.
> 
> Sure, I understand that concern, just wish there was a better approach
> we could use for "DO NOT START THIS SERVER" rather than moving of the
> pg_control file.

As ugly as it is, I have never heard of a better solution.

-- 
  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-general by date:

Previous
From: Stephen Frost
Date:
Subject: Re: PG Upgrade with hardlinks, when to start/stop master and replicas
Next
From: github kran
Date:
Subject: Re: Postgresql RDS DB Latency Chossing Hash join Plan