| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Use-after-free issue in postgres_fdw |
| Date: | 2026-03-24 08:06:38 |
| Message-ID: | acJGDqxU-P-vZ-tA@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 19, 2026 at 11:56:13PM +0900, Etsuro Fujita wrote:
> I got an offline report from my colleague Zhibai Song that
> close_cursor() is called for a freed PGconn, leading to a server
> crash. Here is a reproducer (the original reproducer he provided is a
> bit complex, so I simplified it):
Hmm. We have one isolation test with a pg_terminate_backend() that
checks for a backend terminating, see temp-schema-cleanup.
Do you think that it would be worth having a test for this scenario,
where we could terminate a remote connection? An isolation test may
work, I hope, providing some insurance with the order of the
operations able to trigger the use-after-free behavior.
> I think the root cause is that it is too early to free the PGconn in
> pgfdw_reject_incomplete_xact_state_change() even if the connection is
> in a state where we cannot use it any further; I think we should delay
> that until abort cleanup (ie, pgfdw_xact_callback()). Attached is a
> patch for that.
Removing the early disconnect() means that we should try to cover our
tracks in all the existing ,code paths where we finish the
top-transaction. Looking at the locations of
pgfdw_reset_xact_state(), it looks like you are getting yourself
covered.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lakshmi N | 2026-03-24 08:28:13 | Re: log XLogPrefetch stats at end of recovery |
| Previous Message | Xuneng Zhou | 2026-03-24 08:05:23 | Re: RFC: pg_stat_logmsg |