Thread: pgsql: Fix snapshot reference leak if lo_export fails.
Fix snapshot reference leak if lo_export fails. If lo_export() fails to open the target file or to write to it, it leaks the created LargeObjectDesc and its snapshot in the top-transaction context and resource owner. That's pretty harmless, it's a small leak after all, but it gives the user a "Snapshot reference leak" warning. Fix by using a short-lived memory context and no resource owner for transient LargeObjectDescs that are opened and closed within one function call. The leak is easiest to reproduce with lo_export() on a directory that doesn't exist, but in principle the other lo_* functions could also fail. Backpatch to all supported versions. Reported-by: Andrew B Reviewed-by: Alvaro Herrera Discussion: https://www.postgresql.org/message-id/32bf767a-2d65-71c4-f170-122f416bab7e@iki.fi Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/6b1b405ebfdce9da47f59d8d4144b1168709fbce Modified Files -------------- src/backend/libpq/be-fsstubs.c | 146 ++++++++++++++--------------- src/backend/storage/large_object/inv_api.c | 27 +++--- src/test/regress/input/largeobject.source | 11 +++ src/test/regress/output/largeobject.source | 11 +++ 4 files changed, 104 insertions(+), 91 deletions(-)
> On 3 Nov 2021, at 10:44, Heikki Linnakangas <heikki.linnakangas@iki.fi> wrote: > Fix snapshot reference leak if lo_export fails. This commit seems to lack the update in largeobject_1 as per hamerkop in: https://brekka.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2021-11-03%2010%3A42%3A37 -- Daniel Gustafsson https://vmware.com/
On 03/11/2021 13:06, Daniel Gustafsson wrote: >> On 3 Nov 2021, at 10:44, Heikki Linnakangas <heikki.linnakangas@iki.fi> wrote: > >> Fix snapshot reference leak if lo_export fails. > > This commit seems to lack the update in largeobject_1 as per hamerkop in: Fixed, thanks! I'm a bit surprised none of the other Windows systems on the buildfarm complained. The difference in largeobject_1 output is apparently that the 'tenk.data' file uses Windows line endings. I guess that on all the other Windows hosts, git has been configured to use Unix line endings. - Heikki
> On 3 Nov 2021, at 18:47, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > > On 03/11/2021 13:06, Daniel Gustafsson wrote: >>> On 3 Nov 2021, at 10:44, Heikki Linnakangas <heikki.linnakangas@iki.fi> wrote: >>> Fix snapshot reference leak if lo_export fails. >> This commit seems to lack the update in largeobject_1 as per hamerkop in: > > Fixed, thanks! > > I'm a bit surprised none of the other Windows systems on the buildfarm complained. The difference in largeobject_1 outputis apparently that the 'tenk.data' file uses Windows line endings. I guess that on all the other Windows hosts, githas been configured to use Unix line endings. Interesting, so when hamerkop is offline (which it was for a month) we don't have coverage for Windows line endings? That's worth keeping in mind. -- Daniel Gustafsson https://vmware.com/
On 11/3/21 13:47, Heikki Linnakangas wrote: > On 03/11/2021 13:06, Daniel Gustafsson wrote: >>> On 3 Nov 2021, at 10:44, Heikki Linnakangas >>> <heikki.linnakangas@iki.fi> wrote: >> >>> Fix snapshot reference leak if lo_export fails. >> >> This commit seems to lack the update in largeobject_1 as per hamerkop >> in: > > Fixed, thanks! > > I'm a bit surprised none of the other Windows systems on the buildfarm > complained. The difference in largeobject_1 output is apparently that > the 'tenk.data' file uses Windows line endings. I guess that on all > the other Windows hosts, git has been configured to use Unix line > endings. no, on drongo this comes up blank: git config --get --show-origin core.eol These days I often set: git config --system core.eol lf git config --system core.autocrlf input because it makes repos checked out with Windows native git work nicely with msys git, but I haven't done that on drongo. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com