Re: Avoid memory leaks during base backups
От | Bharath Rupireddy |
---|---|
Тема | Re: Avoid memory leaks during base backups |
Дата | |
Msg-id | CALj2ACUmJ7XAdrPv5yoJKxXdtpy3EZGKoRfL4FG-+kb8nBmXtA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Avoid memory leaks during base backups (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Avoid memory leaks during base backups
|
Список | pgsql-hackers |
On Mon, Oct 17, 2022 at 1:09 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Fri, Oct 14, 2022 at 09:56:31PM +0000, Cary Huang wrote: > > I applied your v5 patch on the current master and run valgrind on it > > while doing a basebackup with simulated error. No memory leak > > related to backup is observed. Regression is also passing. > > Echoing with what I mentioned upthread in [1], I don't quite > understand why this patch needs to touch basebackup.c, walsender.c > and postgres.c. In the case of a replication command processed by a > WAL sender, memory allocations happen in the memory context created > for replication commands, which is itself, as far as I understand, the > message memory context when we get a 'Q' message for a simple query. > Why do we need more code for a cleanup that should be already > happening? Am I missing something obvious? > > [1]: https://www.postgresql.org/message-id/YzPKpKEk/JMjhWEz@paquier.xyz My bad, I missed that. You are right. We have "Replication command context" as a child of "MessageContext" memory context for base backup that gets cleaned upon error in PostgresMain() [1]. > xlogfuncs.c, by storing stuff in the TopMemoryContext of the process > running the SQL commands pg_backup_start/stop() is different, of > course. Perhaps the point of centralizing the base backup context in > xlogbackup.c makes sense, but my guess that it makes more sense to > keep that with the SQL functions as these are the only ones in need of > a cleanup, coming down to the fact that the start and stop functions > happen in different queries, aka these are not bind to a message > context. Yes, they're not related to "MessageContext" memory context. Please see the attached v6 patch that deals with memory leaks for backup SQL-callable functions. [1] (gdb) bt #0 MemoryContextDelete (context=0x558b7cd0de50) at mcxt.c:378 #1 0x0000558b7c655733 in MemoryContextDeleteChildren (context=0x558b7ccda8c0) at mcxt.c:430 #2 0x0000558b7c65546d in MemoryContextReset (context=0x558b7ccda8c0) at mcxt.c:309 #3 0x0000558b7c43b5cd in PostgresMain (dbname=0x558b7cd11fb8 "", username=0x558b7ccd6298 "ubuntu") at postgres.c:4358 #4 0x0000558b7c364a88 in BackendRun (port=0x558b7cd09620) at postmaster.c:4482 #5 0x0000558b7c36431b in BackendStartup (port=0x558b7cd09620) at postmaster.c:4210 #6 0x0000558b7c3603be in ServerLoop () at postmaster.c:1804 #7 0x0000558b7c35fb1b in PostmasterMain (argc=3, argv=0x558b7ccd4200) at postmaster.c:1476 #8 0x0000558b7c229a0e in main (argc=3, argv=0x558b7ccd4200) at main.c:197 -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: