OpenTemporaryFile() vs resowner.c

Started by Thomas Munroalmost 9 years ago2 messageshackers
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

won't retrysuccessCI history

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37686
psql -h localhost -U postgres

Built from patchset v1 (message #1), July 27, 2026 at 09:50 PM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t37686_1 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t37686_1 && git checkout t37686_1

Patchset v1 (message #1) is on t37686_1

Jump to latest
#1Thomas Munro
thomas.munro@gmail.com

Hi hackers,

Andres, Robert and Peter G rightly complained[1]/messages/by-id/20171107210155.kuksdd324kgz5oev@alap3.anarazel.de that my shared
temporary file patch opens a file, then calls
ResourceOwnerEnlargeFiles() which can fail due to lack of memory, and
then registers the file handle to make sure we don't leak it. Doh.
The whole point of the separate ResourceOwnerEnlargeXXX() interface is
to be able to put it before resource acquisition.

The existing OpenTemporaryFile() coding has the same mistake. Please
see attached.

[1]: /messages/by-id/20171107210155.kuksdd324kgz5oev@alap3.anarazel.de

--
Thomas Munro
http://www.enterprisedb.com

Attachments:

t37686_1
fix-file-leak.patchapplication/octet-stream; name=fix-file-leak.patchDownload+7-2
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Thomas Munro (#1)
Re: OpenTemporaryFile() vs resowner.c

Thomas Munro <thomas.munro@enterprisedb.com> writes:

Andres, Robert and Peter G rightly complained[1] that my shared
temporary file patch opens a file, then calls
ResourceOwnerEnlargeFiles() which can fail due to lack of memory, and
then registers the file handle to make sure we don't leak it. Doh.
The whole point of the separate ResourceOwnerEnlargeXXX() interface is
to be able to put it before resource acquisition.

The existing OpenTemporaryFile() coding has the same mistake. Please
see attached.

Pushed. I grepped for related problems and found that IncrBufferRefCount
was also living dangerously, though in a different way: it remembered
a refcount it hadn't actually applied yet.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers