Thread: [HACKERS] OpenTemporaryFile() vs resowner.c

[HACKERS] OpenTemporaryFile() vs resowner.c

From
Thomas Munro
Date:
Hi hackers,

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.

[1] https://www.postgresql.org/message-id/20171107210155.kuksdd324kgz5oev%40alap3.anarazel.de

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

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

Attachment

Re: [HACKERS] OpenTemporaryFile() vs resowner.c

From
Tom Lane
Date:
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