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
adminmailer	Changed adminmailer to read the message from stdin	2021-09-02 00:08:08 +03:00
cinera	The last few stragglers of server setup	2021-09-04 16:57:16 -05:00
local	Redirect old blog URLs to new	2021-09-20 10:17:53 -05:00
public	Added basic usage tracking for posts.	2021-09-22 22:18:39 +03:00
server	Add a meta makefile update command	2021-09-09 11:02:09 -05:00
src	Ensure that that one goroutine exits when the iterator is closed	2021-10-21 01:42:34 -05:00
.gitignore	No longer require a migration in seedfile	2021-09-05 19:43:49 -05:00
go.mod	Save Discord messages and attachments	2021-08-21 11:15:27 -05:00
go.sum	Save Discord messages and attachments	2021-08-21 11:15:27 -05:00