Fwd: 8.0 Beta3 worked, RC1 didn't!
От | Tom Lane |
---|---|
Тема | Fwd: 8.0 Beta3 worked, RC1 didn't! |
Дата | |
Msg-id | 8122.1103900456@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Fwd: 8.0 Beta3 worked, RC1 didn't!
(Gary Doades <gpd@gpdnet.co.uk>)
Re: Fwd: 8.0 Beta3 worked, RC1 didn't! (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers-win32 |
Forwarding the attached in case anyone missed it on -general. The shmem attach address shown in his messages (00DC0000) seems mighty low. What I am suspecting is: 1. Postmaster boots, creates shmem, and for some idiotic reason 2003 Server creates the shmem segment just above the end of regular memory. 2. When subprocesses launch and re-read GUC settings, for one reason or another they use up a little more RAM than the postmaster did. 3. Subprocesses fail to attach to shmem because the target address is now in their regular RAM range. I don't know why 2003 Server has such a brain-dead choice of shmem address assignment, nor why listen_addresses might prompt a little extra growth of RAM usage. But the theory seems to fit the available facts. If this is correct then we have to do something to force a smarter choice of shmem address on Windows. One brute-force way to do it might be to malloc a couple hundred K just before the postmaster attaches to shmem, and then release? Theory B is that somehow UsedShmemSegAddr is not being passed down accurately in this case, but that seems a mite improbable. regards, tom lane ------- Forwarded Message Date: 23 Dec 2004 08:33:12 -0800 From: nico@def2shoot.com (Nicolas COUSSEMACQ) To: pgsql-general@postgresql.org Subject: [GENERAL] 8.0 Beta3 worked, RC1 didn't! I have the same problem ! When I setup Postgres 8.0 Beta 4 on a Windows Xp or 2003 Server, it works parfectly with parameter listen_adresses set to '*' or localhost. I have been testing Beta5, RC1 and RC2 on my XP workstation and there is no problem, event if I accept external connections ( listen_adresses = '*'). Then I tried to setup Beta5, RC1 or RC2 on a station with 2003 Server, I can only acces the Database when listen_adresses = localhost. If i set listen_adresses = '*', i have a connection problem in PgAdmin saying "Could not recieve server response to SSL negociation packet : Connection reset by peer (0X00002746/10054). It appends when I launch pgadmin directly logged on the station, when i'm connected with remote access and even from my XP workstation. The log file contains many lines such these ones : 2004-12-23 16:55:17 FATAL: could not attach to proper memory at fixed address: shmget(key=5432001, addr=00DC0000) failed: Invalid argument 2004-12-23 16:55:17 FATAL: could not attach to proper memory at fixed address: shmget(key=5432001, addr=00DC0000) failed: Invalid argument 2004-12-23 16:55:17 LOG: background writer process (PID 680) exited with exit code 0 2004-12-23 16:55:17 LOG: terminating any other active server processes 2004-12-23 16:55:17 LOG: all server processes terminated; reinitializing If I switch the listen_addresses parameter back to localhost', I can connect to the DB in PgAdmin from the server screen or remote acces. Those these information help you ? ""A. Mous"" <a.mous@shaw.ca> a �crit dans le message de news:000801c4e7d1$058c5300$6500a8c0@PETER... > Hi all, > > I'm using psql 8.0.0 on a client's site who's running win server 2003. > We've had him on beta 3 for some time, and no problems at all (yes, in a > sense, he is a beta tester as well, but doesn't know it!). Today I tried to > upgrade the db to RC1 and had some problems. > > Remote clients connect to this database, so I have to set listen_addresses = > '*' in the posrgresql.conf file. This is the only change to the config > file. Doing this with RC1 and trying to connect locally with through psql > resulted in the following error message: > > "could not receive server response to SSL negotiation packet; connection > reset by peer (0x00002746/10054)" > > Removing the modified line in the config file resolved the problem > (locally), however, no clients can connect! Beta 3 does not seem to have > this issue, so we had to revert back to it for now. > > I would appreciate any ideas that some of you may have. Much thanks, > > -Peter > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings ------- End of Forwarded Message
В списке pgsql-hackers-win32 по дате отправления: