Re: Fwd: 8.0 Beta3 worked, RC1 didn't!

I have tried to, and am unable to reproduce this on any of my 2003 machines. I have tried with both RC1 and RC2.

For those who reported the problem:
1) To reproduce, I installed from the MSI installer and just changed the listen_address parameter. Did you change anything *else* in your configuration? In postgresql.conf or anywhere else in pg?

2) Does this happen in a freshly initdb:ed database, or only when there is data? Does this happen directly after server (service) startup, or does it require the database to be running for a while with connections/disconnections before it happens?

3) Do you have any non-OS software installed on the machine(s) that are showing this problem?

4) What's the value of shared_buffers in postgresql.conf?

Tom,
why is DC000000 so low? That's still 10Mb into the process, right? Granted, it's not high, but it's not *that* low. (A simple test program with all parameters at default get it's first address allocated at 003D2438 for me. A freshly MapViewOfFile()d memory ends up at 003f0000. If I go for a larger test block (such as 50Mb), the mapped memory is moved up to 004d0000. I get very simlar results on XP and 2003.

There are unfortunatly several places in the shmem code that will return EINVAL. So there is currently no way to detect exactly where the problem is. What do you think of adding a couple of elog()s at each place to help identifying them?

//Magnus

>-----Original Message-----
>From: pgsql-hackers-win32-owner(at)postgresql(dot)org
>[mailto:pgsql-hackers-win32-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
>Sent: den 24 december 2004 16:01
>To: pgsql-hackers-win32(at)postgresql(dot)org
>Subject: [pgsql-hackers-win32] 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: nico(at)def2shoot(dot)com (Nicolas COUSSEMACQ)
>To: pgsql-general(at)postgresql(dot)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(dot)mous(at)shaw(dot)ca> a écrit dans le message de
>news:000801c4e7d1$058c5300$6500a8c0(at)PETER(dot)(dot)(dot)
>> 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
>