| From: | Andy Fan <zhihuifan1213(at)163(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | ProcArrayAdd/ProcArrayRemove in Prepared Transaction |
| Date: | 2026-08-21 07:28:51 |
| Message-ID: | 87a4qghqz0.fsf@163.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Currently when we create a PreparedTransaction, we call ProcArrayAdd.
Then when we FinishPreparedTransaction, we canl ProcArrayRemove. Both
functions need do lots of memmove when holding a LW_EXCLUSIVE lock on
ProcArrayLock. I guess this would be a common bottleneck on a
PostgreSQL-based distributed database.
Should we do something to improve this? The direct idea in my mind is we
can cache N PGPROCs for prepared xact in ProcArray, it should be the
number of concurrently *active* preapred transaction which maybe much
less than max_prepared_xacts value, so it probably not too bad for
ProcArray Scan. Then we can remove the both ProcArrayAdd and
ProcArrayRemove. However besides we have to manage the PGPROC state
carefully for these cached PGPROCs, another troubles is the PGPROC is
bind to database and user, this make them hard to manage, any idea how
to handle this?
I want to PoC the above idea, but I hope some difference voice or the
suggestion about the database/user stuff.
--
Best Regards
Andy Fan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nitin Jadhav | 2026-08-21 07:40:21 | Re: pg_dump: assert failure sorting casts/transforms |
| Previous Message | Michael Paquier | 2026-08-21 07:20:12 | Re: Reduce memory overheads for storing a Memoize tuple |