Re: autovacuum launcher process eating up 17G+ of ram?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Excerpts from Tom Lane's message of lun oct 25 16:57:10 -0300 2010:

> It looks to me like the problem is that get_database_list()
> intentionally pushes its result into a long-lived context, and then the
> result is never cleaned up.  It doesn't help any that it does a lot of
> leaky things like heap_beginscan with CurrentMemoryContext totally
> unnecessarily pointing at the long-lived context.
> 
> I'm not sure what the intent was here, but it's pretty broken as-is.
> Alvaro, what did you have in mind?  Should this be using a less
> long-lived context, or do we need code to free an avw_dbase list?

Sorry for not noticing this earlier.  Seems my mail filters are broken
:-(  Thanks Tom for the ping via private email.

Yes, get_database_list is clearly broken as is.  I don't remember why
it's coded like this; this memcxt shuffling was introducing in the 9.0
rewrite to read pg_database directly instead of the flat file.

The right way for it to work seems to be to allocate the output list in
the caller's context; both current callers are in a throwaway context and
so the allocated list will go away automatically when they're done with
the list.

Patch for this is attached (applies cleanly to 9.0 and HEAD; 8.4 doesn't
need to be patched, but I'll run the test case now just to be sure.)

-- 
Ãlvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment: 0001-Fix-permanent-memory-leak-in-autovacuum-launcher.patch
Description: Binary data

-- 
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux