Jim Nasby-5 wrote > On 3/5/15 2:06 PM, wambacher wrote: > Crashed? Or hit by the OOM killer? What's the log say? killed by OOM, but has only 1.2 GB mem, which is ok to me. > While this is going on you might as well disable autovac for that table. > It'll keep crashing and will interfere with your manual vacuums. did it this morning, the crash was running "vacuum verbose planet_osm_ways" by cli. > It sounds at this point like the problem is in vacuuming, not analyze. > Can you confirm? If so, please forgo analyzing the table until we can > get vacuum figured out. yes, it's the vacuum task. > What's the largest memory size that a vacuum/autovac against that table > gets to compared to other backends? You meantioned 80-90% of memory > before, but I don't know if that was for analyze or what. vacuum > I wonder if we have some kind of memory leak in GIN's vacuum support... may be. At least i did: - droped the gin-index - cluster - analyze - vacuum all without any problems. now i'll add the index again and tomorrow do another vacuum by hand. 2:30 in germany, feeling tired ;) Regards walter -- View this message in context: http://postgresql.nabble.com/autovacuum-worker-running-amok-and-me-too-tp5840299p5840730.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
