From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Avoid memory leaks during base backups |
Date: | 2022-09-26 14:04:42 |
Message-ID: | 3438232.1664201082@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> writes:
> Postgres currently can leak memory if a failure occurs during base
> backup in do_pg_backup_start() or do_pg_backup_stop() or
> perform_base_backup(). The palloc'd memory such as backup_state or
> tablespace_map in xlogfuncs.c or basebackup.c or tablespaceinfo or the
> memory that gets allocated by bbsink_begin_backup() in
> perform_base_backup() or any other, is left-out which may cause memory
> bloat on the server eventually. To experience this issue, run
> pg_basebackup with --label name longer than 1024 characters and
> observe memory with watch command, the memory usage goes up.
> It looks like the memory leak issue has been there for quite some
> time, discussed in [1].
> I'm proposing a patch that leverages the error callback mechanism and
> memory context.
This ... seems like inventing your own shape of wheel. The
normal mechanism for preventing this type of leak is to put the
allocations in a memory context that can be reset or deallocated
in mainline code at the end of the operation. I do not think that
having an errcontext callback with side-effects like deallocating
memory is even remotely safe, and it's certainly a first-order
abuse of that mechanism.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Wolfgang Walther | 2022-09-26 14:04:49 | Re: Allow foreign keys to reference a superset of unique columns |
Previous Message | Wolfgang Walther | 2022-09-26 13:59:41 | Re: Allow foreign keys to reference a superset of unique columns |