| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Make PQgetResult() not return NULL on out-of-memory error |
| Date: | 2025-11-12 09:09:28 |
| Message-ID: | CAHGQGwG_sv750JMUvN0A6WB7HTVTYmLsDNP3KfZhe1RSoodqjA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > Therefore, I wonder about closing the connection and resetting the status
> > when OOM_result is retunred, by callling pqDropConnection() as handleFatalError() does.
> > In this case, the connection status should also be set to CONNECTINO_BAD.
There are many code paths in libpq that can trigger an out-of-memory error.
However, this patch makes libpq drop the connection when OOM_result is returned,
which likely covers only a subset of those cases. So I'm not sure dropping
the connection only for OOM_result would meaningfully improve things.
Perhaps it would be more consistent to drop the connection for any
internal libpq error
such as out-of-memory, though that might require invasive code changes and coul
break existing applications, I'm afraid.
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2025-11-12 09:10:28 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Steven Niu | 2025-11-12 08:47:20 | Re: Fix incorrect assignment of InvalidXLogRecPtr to a non-LSN variable. |