Re: Yet another failure mode in pg_upgrade

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Yet another failure mode in pg_upgrade
Дата
Msg-id 20120903135222.GC24132@momjian.us
обсуждение исходный текст
Ответ на Re: Yet another failure mode in pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Yet another failure mode in pg_upgrade
Re: Yet another failure mode in pg_upgrade
Re: Yet another failure mode in pg_upgrade
Список 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. +

Вложения

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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: 9.2: Describing a security barrier view in psql
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Proof of concept: standalone backend with full FE/BE protocol