Re: Memory leak in WAL sender with pgoutput (v10~)
| От | Euler Taveira |
|---|---|
| Тема | Re: Memory leak in WAL sender with pgoutput (v10~) |
| Дата | |
| Msg-id | 1baea8f8-6c13-42a5-abee-934d452707ef@app.fastmail.com обсуждение исходный текст |
| Ответ на | Re: Memory leak in WAL sender with pgoutput (v10~) (Amit Kapila <amit.kapila16@gmail.com>) |
| Список | pgsql-hackers |
On Tue, Dec 3, 2024, at 7:41 PM, Michael Paquier wrote:
On Tue, Dec 03, 2024 at 02:45:22PM +0100, Alvaro Herrera wrote:> If we don't want to accept that risk (for which I see no argument, but> happy to be proven wrong), I would suggest to use the foreach-pfree> pattern Michael first proposed for the backbranches, and the new memory> context in master. I think this is conducive to better coding overall> as we clean things up in this area.Is it really worth betting on nobody doing something that does asizeof(PGOutputData) for the stable branches? People like doing fancythings, and we would not hear about such problems except if we pushthe button making it a possibility because compiled code suddenlybreaks after a minor release update of the core engine.
Although, Debian code search [1] says this data structure is not used outside
PostgreSQL, I wouldn't risk breaking third-party extensions during a minor
upgrade (even if it is known that such data structure is from that particular
output plugin -- pgoutput -- and other output plugins generally have its own
data structure). +1 from Alvaro's proposal.
В списке pgsql-hackers по дате отправления: