| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17828: postgres_fdw leaks file descriptors on error and aborts aborted transaction in lack of fds |
| Date: | 2024-02-09 00:20:35 |
| Message-ID: | 1278317.1707438035@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andres Freund <andres(at)anarazel(dot)de> writes:
> I might be missing something here, but leaving the concrete crash aside, why
> is it ok for pgfdw_get_cleanup_result() etc to block during abort processing?
It's not pretty, for sure. I thought briefly about postponing the
cleanup until we next try to use the connection, but I fear the
semantic side-effects of that would be catastrophic. We can't leave
the remote's query sitting open long after the local transaction has
been canceled --- that risks undetected deadlocks, at the least.
I think all we can do is try to reduce the risk of failure during
transaction cleanup.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2024-02-09 00:40:05 | Re: BUG #17828: postgres_fdw leaks file descriptors on error and aborts aborted transaction in lack of fds |
| Previous Message | Thomas Munro | 2024-02-09 00:09:48 | Re: BUG #17828: postgres_fdw leaks file descriptors on error and aborts aborted transaction in lack of fds |