Re: [HACKERS] OpenTemporaryFile() vs resowner.c
Thomas Munrowrites: > 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
[HACKERS] OpenTemporaryFile() vs resowner.c
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 fix-file-leak.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers