was there a change in FreeBSD SHM implementation from 4.4 to 4.6? (postgres trouble)

I have a dual cpu box with 2GB RAM dedicated to running Postgres.
Last week, I upgraded FreeBSD from 4.4-STABLE to 4.6-RELEASE-p1.  When
I went to restart postgres, it complained that it could not allocate
the shared memory segment.  I'm running Postgres 7.2.1.

For those familiar with postgres, I was using shared_buffers=100000
with 4.4, but had to back that down to 32000 for 4.6.  This is
obviously impacting performance...

The kern.ipc.* settings have not changed.  In my /etc/sysctl.conf
file, I set

kern.ipc.shmmax=268435456
kern.ipc.shmall=65535
kern.ipc.shm_use_phys=1

With FreeBSD 4.6, I even upped the shmmax to 1073741824 to no avail.
I also set this in the kernel (so as to eliminate any issues with
setting it at boot time).

However, it does produce a most peculiar error message when running
postgres:

-- cut here --
IpcMemoryCreate: shmget(key=5432001, size=665346048, 03600) failed: Cannot allocate memory

This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space.
To reduce the request size (currently 665346048 bytes), reduce
PostgreSQL's shared_buffers parameter (currently 80000) and/or
its max_connections parameter (currently 48).
-- cut here --


Now, by my arithmetic, 665346048 is certainly less than 1073741824 by
quite a bit.

I did not recompile postgres after the FreeBSD upgrade.

Has something changed from 4.4-STABLE that would cause such a failure?

The funny thing is that it worked just fine with FBSD 4.4 and the
lower setting of shmmax (even with 100000 shared_buffers), so
something is making postgres try to allocate a larger hunk of memory.
I just don't know what.

Any advice would be appreciated.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.                Khera Communications, Inc.
Internet: khera@kciLink.com       Rockville, MD       +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/