Ben Visness 623aaec9d8 Ensure that that one goroutine exits when the iterator is closed ... This resolves that completely nonsensical memory leak situation. As far as we can understand, the cause was a hodgepodge of the following: - There is some buffer sharing going on deep in pgx - Queries made with a cancellable but long-running context (like that used for background jobs) would leave iterator-related goroutines hanging - These goroutines had a pgx `rows` object in their closures, preventing the row stuff from being garbage collected - If you look at a profile, it all appears to be caused by whatever functions were doing the most database queries / reading the most from Postgres. In fact those things were _allocating_ the most but not retaining any of that data - it was being retained by these other goroutines because of magic buffer sharing huzzah I love it We could have solved this in approximately 30 minutes if Go could actually tell us what is keeping things alive in the heap, instead of just tracking allocations.		2021-10-21 01:42:34 -05:00
..
db.go	Ensure that that one goroutine exits when the iterator is closed	2021-10-21 01:42:34 -05:00
db_test.go	Switch to centralized helpers for fetching threads/posts	2021-09-22 23:48:31 -05:00
query_builder.go	Switch to centralized helpers for fetching threads/posts	2021-09-22 23:48:31 -05:00