Re: Yet another failure mode in pg_upgrade
От | Bruce Momjian |
---|---|
Тема | Re: Yet another failure mode in pg_upgrade |
Дата | |
Msg-id | 20120902111701.GB21043@momjian.us обсуждение исходный текст |
Ответ на | Re: Yet another failure mode in pg_upgrade (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Yet another failure mode in pg_upgrade
|
Список | pgsql-hackers |
On Sun, Sep 2, 2012 at 01:06:28AM -0400, Robert Haas wrote: > > For "live check" operation, you are checking a running server, so > > assuming the socket is in the current directory is not going to work. > > What the code does is to read the 5th line from the running server's > > postmaster.pid file, which has the socket directory in PG >= 9.1. For > > pre-9.1, pg_upgrade uses the compiled-in defaults for socket directory. > > If the defaults are different between the two servers, the new binaries, > > e.g. pg_dump, will not work. The fix is for the user to set pg_upgrade > > -O to match the old socket directory, and set PGHOST before running > > pg_upgrade. I could not find a good way to generate a proper error > > message because we are blind to the socket directory in pre-9.1. > > Frankly, this is a problem if the old pre-9.1 server is running in a > > user-configured socket directory too, so a documentation addition seems > > right here. > > > > So, in summary, this patch moves the socket directory to the current > > directory all but live check operation, and handles different socket > > directories for old cluster >= 9.1. I have added a documentation > > mention of how to make this work for for pre-9.1 old servers. > > I don't think this is reducing the number of failure modes; it's just > changing it from one set of obscure cases to a slightly different set > of obscure cases. Tom reported problems with having old/new with different default socket locations. This fixes that, and reduces the possibility of acciental connections. What problems does this add? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: