Re: Yet another failure mode in pg_upgrade - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Yet another failure mode in pg_upgrade
Date
Msg-id 20120903135222.GC24132@momjian.us
Whole thread Raw
In response to Re: Yet another failure mode in pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Yet another failure mode in pg_upgrade
Re: Yet another failure mode in pg_upgrade
Re: Yet another failure mode in pg_upgrade
List pgsql-hackers
On Sun, Sep  2, 2012 at 11:47:06PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Updated patch attached.
>
> [ looks at that for a bit... ]  Now I see why you were on about that:
> the method you used here requires both clusters to have the same socket
> directory.  Which is silly and unnecessary.  Revised patch attached.

I was trying to avoid setting the host for every client database
application, so I set PGHOST, but your use of get_db_conn() has
simplified that, which I had not considered.  Also, you will need to
update the comment above cluster_conn_opts() to match your new function
name.

I am working on an additional enhancement that also pulls the live
cluster's port number from the postmaster.pid file.  I am attaching the
part of my patch that was modified to add that feature.  This allows
live checks without requiring any port numbers to be specified.  Let me
know if you would like me to email you that merged into your patch, if
you want it for 9.2.

Also, I don't see my doc addition on your patch;  was that intentional?

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: 9.2: Describing a security barrier view in psql
Next
From: Amit Kapila
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol