Win 32 'could not attach to proper memory at fixed address'

Running RC1 on Windows 2003 Server I get the following:

2004-12-13 13:01:11 FATAL: could not attach to proper memory
at fixed address:
shmget(key=5432001, addr=00DB0000) failed: Invalid argument
2004-12-13 13:01:11 FATAL: could not attach to proper memory
at fixed address:
shmget(key=5432001, addr=00DB0000) failed: Invalid argument
2004-12-13 13:01:11 LOG: background writer process (PID
3548) exited with exit code 0
2004-12-13 13:01:11 LOG: terminating any other active server
processes
2004-12-13 13:01:11 LOG: all server processes terminated;
reinitializing

I noticed that there are a couple of references to this on
the mailing list however the 'Invalid argument' part of the
message appears to be different.

The problem can be worked around (if you are running locally)
by changing the postgresql.conf from:
listen_addresses = '*'
to:
listen_addresses = '127.0.0.1'

You're saying this only happens if listen_addresses='*'? *very*
interesting.

Are you running this off the console or through a RDP session?

//Magnus

Added to TODO for Win32:

o Allow the shared memory address to be configured via GUC

This is something we knew might be required and now I think it is
required. Using a fixed address was always pretty crazy.

---------------------------------------------------------------------------

Magnus Hagander wrote:

Running RC1 on Windows 2003 Server I get the following:

2004-12-13 13:01:11 FATAL: could not attach to proper memory
at fixed address:
shmget(key=5432001, addr=00DB0000) failed: Invalid argument
2004-12-13 13:01:11 FATAL: could not attach to proper memory
at fixed address:
shmget(key=5432001, addr=00DB0000) failed: Invalid argument
2004-12-13 13:01:11 LOG: background writer process (PID
3548) exited with exit code 0
2004-12-13 13:01:11 LOG: terminating any other active server
processes
2004-12-13 13:01:11 LOG: all server processes terminated;
reinitializing

I noticed that there are a couple of references to this on
the mailing list however the 'Invalid argument' part of the
message appears to be different.

The problem can be worked around (if you are running locally)
by changing the postgresql.conf from:
listen_addresses = '*'
to:
listen_addresses = '127.0.0.1'

You're saying this only happens if listen_addresses='*'? *very*
interesting.

Are you running this off the console or through a RDP session?

//Magnus

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

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Added to TODO for Win32:
o Allow the shared memory address to be configured via GUC
This is something we knew might be required and now I think it is
required. Using a fixed address was always pretty crazy.

I see no proof of that at all in this bug report. The postmaster has
evidently managed to create the segment, so the address per se is not
the problem.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Added to TODO for Win32:
o Allow the shared memory address to be configured via GUC
This is something we knew might be required and now I think it is
required. Using a fixed address was always pretty crazy.

I see no proof of that at all in this bug report. The postmaster has
evidently managed to create the segment, so the address per se is not
the problem.

Really? You do realize we just choose a fixed address on Win32, right?

I will remove the item and see how it plays out though.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

o Allow the shared memory address to be configured via GUC
This is something we knew might be required and now I think it is
required. Using a fixed address was always pretty crazy.

I see no proof of that at all in this bug report. The postmaster has
evidently managed to create the segment, so the address per se is not
the problem.

Really? You do realize we just choose a fixed address on Win32, right?

I didn't say that might not be a problem; I said this bug report doesn't
prove that it's a problem. (And perhaps more to the point, I doubt
adding such a GUC var would fix this report.)

regards, tom lane

shmget(key=5432001, addr=00DB0000) failed: Invalid argument
2004-12-13 13:01:11 FATAL: could not attach to proper memory
at fixed address:
shmget(key=5432001, addr=00DB0000) failed: Invalid argument
2004-12-13 13:01:11 LOG: background writer process (PID
3548) exited with exit code 0
2004-12-13 13:01:11 LOG: terminating any other active server
processes
2004-12-13 13:01:11 LOG: all server processes terminated;
reinitializing

I noticed that there are a couple of references to this on
the mailing list however the 'Invalid argument' part of the
message appears to be different.

The problem can be worked around (if you are running locally)
by changing the postgresql.conf from:
listen_addresses = '*'
to:
listen_addresses = '127.0.0.1'

You're saying this only happens if listen_addresses='*'? *very*
interesting.

Yes it listens on localhost but not the external IP addresses.

Are you running this off the console or through a RDP session?

The installation was done from the console. Restarts and config changes have
been done using RDP.

Due to the listen address differences I'm inclined to think it may be some OS
configuration problem. There isn't any firewall or Anti-Virus S/W installed
but I'll try a fresh install and see how I get on. I'll also see if I can log
the install to see if that turns anything up.

Thanks,
Bryan