Fwd: 8.0 Beta3 worked, RC1 didn't!

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:    [email protected] (Nicolas COUSSEMACQ)
To:      [email protected]
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"" <[email protected]> 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


---------------------------(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