| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: OpenTemporaryFile() vs resowner.c |
| Date: | 2017-11-08 21:54:44 |
| Message-ID: | 19645.1510178084@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lucas B | 2017-11-08 22:02:30 | Re: Early locking option to parallel backup |
| Previous Message | Thomas Munro | 2017-11-08 21:23:07 | Re: Pg V10: Patch for bug in bonjour support |