Gavin Kistner <phrogz@xxxxxxx> writes: > On Apr 30, 2010, at 3:35 PM, Tom Lane wrote: >> Does the theory of a pre-existing smaller shmem segment make sense from >> your end? In particular, had you previously had another Postgres server >> running on that machine, and perhaps killed it ungracefully? > It seems probably that you have hit the nail squarely on the head. I had installed from the one-click (which was working with the memory changes supplied in the README), and IIRC I tried to kill a few processes in preparation for a manual uninstall before I found the supplied uninstall app. I then compiled and installed from source. When that failed as described earlier, all changes I made to the settings were (as you guessed) through the sysctl -w option without a reboot. The first reboot I had was after I replaced my sysctl.conf wholesale with yours, and all was well. Yeah, I was able to reproduce the problem locally by kill -9'ing the postmaster and then enlarging max_connections in postgresql.conf before trying to restart. In your case it might've been caused by the new version needing a bit more shared memory rather than by any change in parameter settings, but the basic issue seems pretty clear now. I've applied a patch to our CVS to make PG behave more sanely in this case. It does do the right thing if it recognizes that the shmget failure is due to a pre-existing segment, but we weren't being sufficiently careful about distinguishing that from a bad size request. Thanks for the report! regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
