On Wed, Oct 7, 2026 at 11:53 AM Ashutosh Sharma <[email protected]> wrote: > > Hi, > > RecoverPreparedTransactions() currently emits one LOG message for > every prepared transaction restored at the end of recovery. > > With many unresolved prepared transactions, this produces substantial > log output during promotion. Writing these messages can also delay > completion of recovery. > > This patch moves the per-transaction message from LOG to DEBUG1. The > transaction ID and epoch remain available when detailed logging is > enabled. After recovery, one LOG message reports the total number of > successfully recovered prepared transactions. > > For example: > > LOG: recovered 50000 prepared transactions > > I performed preliminary tests using a physical standby and empty > prepared transactions on my local VM and here are the results that I > could see: > > Prepared xacts Without patch With patch Time saved > --------------- ------------ ----------------------- ---------- > 10,000 1.544 s 0.615 s 0.929 s > 25,000 3.936 s 2.433 s 1.503 s > 50,000 9.788 s 6.263 s 3.525 s > > The patched version reduced recovery time in both tests while avoiding > thousands of repetitive LOG messages. > > The patch does not change prepared transaction recovery or on disk state. > > Transaction level diagnostics remain available with log_min_messages = debug1. > > Please take a look at the attached patch and let me know your > thoughts. I have also attached the test-script I used to create > prepared transactions for the test results shown above. > > The test scripts can be used as follows: > > ./create_prepared_transactions.sh <prepared_transactions_count> <primary_port>
Hi Ashutosh, 1. I've always also wondered too why we are spamming the log with per-2pc recovered transaction details too back in the day. It's hard to read in real production recovery scenarios. 2. Sadly I couldn't repro the performance benefit. I've tried even with syslog, so perphas this is something with the VM on your side? What's the profile/reason/specs that cause lack of ereport() to causes such a big boost? In my case even (lack of) 50k rows like that, each taking ~111 bytes ( datetime+tz+pid+"LOG: recovering prepared transaction 29635 of epoch 0 from shared memory" is something like just ~5MB happily accepted by writeback/ dirty mem, so technically it should not cause any I/O performance issues. I've tried to benchmark this even with local rsyslogd and also got not improvement. So at least in my case, it's cheap? 3. Please register in the commitfest, so the email doesn't get lost, or at least I couldn't find it. So +1 from to avoid log clutter (log readability), but not as performance enhacement as I couldn't repro the benefit. -J.
