On 07/02/11 09:52, felix wrote: > So is it normal for postgres to report that it failed to shut down, > operate for an hour and then go ahead and restart itself ? That's pretty wacky. Did you shut it down via pg_ctl or using an init script / "service" command in your OS? It shouldn't matter, but it'd be good to know. If the problem is with an init script, then knowing which OS and version you're on would help. If it was with psql directly, that's something that can be looked into. > this was changing one configuration parameter. something I was advised > to do, read about quite a bit, tested on my development server (mac) and > then proceeded to do at 6 am on Sunday morning, our slowest time. System V shared memory is awful - but it's really the only reasonable alternative for a multi-process (rather than multi-threaded) server. PostgreSQL could use mmap()ed temp files, but that'd add additional overheads and they'd potentially get flushed from main memory unless the memory was mlock()ed. As mlock() has similar limits and configuration methods to system V shared memory, you get back to the same problem in a slightly different form. What would possibly help would be if Pg could fall back to lower shared_buffers automatically, screaming about it in the logs but still launching. OTOH, many people don't check the logs, so they'd think their new setting had taken effect and it hadn't - you've traded one usability problem for another. Even if Pg issued WARNING messages to each client that connected, lots of (non-psql) clients don't display them, so many users would never know. Do you have a suggestion about how to do this better? The current approach is known to be rather unlovely, but nobody's come up with a better one that works reasonably and doesn't trample on other System V shared memory users that may exist on the system. > so does the above mean that I don't have to restart the entire server, > just postgres ? I assumed that changing kernel settings means rebooting > the server. Nope. sysctl settings like shmmax may be changed on the fly. -- System & Network Administrator POST Newspapers -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
