11 days ago
I created a simple database today. No traffic but it does have two configuration changes. 1 is enabling logical replication for PowerSync. The other is PITR. As you can see as soon as PITR was enabled memory sharply increases. Note that there is no load on the system yet.
I staged and rolled back a disabling of the feature and memory immediately returned to normal (~40mb rather than 2GB)
Has anyone else experienced this kind of runaway memory from backups?
Attachments
3 Replies
Status changed to Open Railway • 11 days ago
11 days ago
I’ve run into this before—it’s usually a quirk with how Postgres handles memory when you pair logical replication with PITR on a completely idle database.
Even with zero traffic, Postgres is writing internal state changes and checkpoints to the WAL. Because wal_level = logical is active but you don't have an active subscriber actively pulling and flushing that stream yet, the walsender process caches all those internal changes in memory. Postgres defaults logical_decoding_work_mem quite high (often up to 1.5GB–2GB), so it just sits there soaking up RAM instead of spilling to disk.
If you want to keep PITR on without the massive memory spike, try lowering that buffer limit in your config:
ALTER SYSTEM SET logical_decoding_work_mem = '64MB';
Once you actually connect PowerSync and it starts consuming the replication slot, that memory footprint should drop back down and behave normally!
I’ve run into this before—it’s usually a quirk with how Postgres handles memory when you pair logical replication with PITR on a completely idle database. Even with zero traffic, Postgres is writing internal state changes and checkpoints to the WAL. Because wal_level = logical is active but you don't have an active subscriber actively pulling and flushing that stream yet, the walsender process caches all those internal changes in memory. Postgres defaults logical_decoding_work_mem quite high (often up to 1.5GB–2GB), so it just sits there soaking up RAM instead of spilling to disk. If you want to keep PITR on without the massive memory spike, try lowering that buffer limit in your config: ALTER SYSTEM SET logical_decoding_work_mem = '64MB'; Once you actually connect PowerSync and it starts consuming the replication slot, that memory footprint should drop back down and behave normally!
11 days ago
So there was an active PowerSync instance connected to it… but that does make sense 🤔
ill give that config a try and see if it helps as well. It should start having load within the week and Ill enable it then to validate
4 days ago
Whoops, that was a work account 😊