Re: BUG #6347: Reopening bug #6085
От | Bruce Momjian |
---|---|
Тема | Re: BUG #6347: Reopening bug #6085 |
Дата | |
Msg-id | 20120203185229.GC11939@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #6347: Reopening bug #6085 (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: BUG #6347: Reopening bug #6085
(Alvaro Herrera <alvherre@commandprompt.com>)
|
Список | pgsql-bugs |
On Fri, Feb 03, 2012 at 09:59:07AM -0500, Bruce Momjian wrote: > On Mon, Dec 19, 2011 at 03:06:31PM +0000, alexander.fortin@gmail.com wrote: > > The following bug has been logged on the website: > > > > Bug reference: 6347 > > Logged by: Alexander Fortin > > Email address: alexander.fortin@gmail.com > > PostgreSQL version: 9.1.2 > > Operating system: Ubuntu 10.04.3 > > Description: > > > > Hi folks. I'm testing 9.1.2 (source compiled) pg_upgrade (upgrading from > > 8.4.9) and it seems that the problem exposed in bug #6085 is still there. In > > my case, the only way to make pg_upgrade work is to actually force > > unix_socket_directory = '/tmp/' for the 8.4.9 cluster. > > > > Running in verbose mode > > Performing Consistency Checks on Old Live Server > > ------------------------------------------------ > > Checking current, bin, and data directories ok > > Checking cluster versions ok > > connection to database failed: could not connect to server: No such file or > > directory > > Is the server running locally and accepting > > connections on Unix domain socket "/tmp/.s.PGSQL.5432"? > > Yes. I wasn't clear in my email reply: > > http://archives.postgresql.org/pgsql-bugs/2011-07/msg00092.php > > When I said this will be fixed in 9.1, I meant pg_ctl will work in 9.1 > for non-default socket directories, but when the 9.1 pg_upgrade accesses > the 8.4 server, it has to use the 8.4 pg_ctl to do it, and that can't be > fixed in a back-branch. > > I think we can only call this fixed when the old and new server is >= PG > 9.1. Yeah, this isn't good, but it is the best we can do. Actually, thinking more about this, the old pg_upgrade didn't use pg_ctl wait/-w mode, but rather kept trying to connect until the server was up. Once pg_ctl -w worked in more cases in PG 9.1, the new pg_upgrade started using pg_ctl -w, but I didn't consider that we were unable to fix pg_ctl -w for non-standard settings in back branches. This can be seen as a regression in pg_upgrade functionality. Not sure what we can do about this, but perhaps there should be a mention in the pg_upgrad docs. I am going to wait to see if anyone else reports this problem --- the last report was against Postgres 9.0 in July, 2011. FYI, here is the 9.1 relesase not mention of the fix: Improve <application>pg_ctl</> start's "wait" (-w) option (Bruce Momjian, Tom Lane) The wait mode is now significantly more robust. It will not get confused by non-default postmaster port numbers, non-default Unix-domain socket locations, permission problems, or stale postmaster lock files. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Dharmendra GoyalДата:
Сообщение: Re: BUG #6404: postgres account not created during unattended install