Re: Reduce logging during prepared transaction recovery

Hi,

On Mon, Oct 12, 2026 at 2:13 PM Jakub Wartak
<jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
>
> On Wed, Oct 7, 2026 at 11:53 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
> >
> > 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.

The primary motivation for this change is to reduce log clutter. In
our environment, these logs are forwarded to remote log storage, so
emitting one message per recovered prepared transaction also creates
unnecessary log volume and downstream processing.

I agree that any performance improvement is secondary and
environment-dependent. The preliminary local testing I mentioned
showed a minor improvement, but since it has not been reproducible
elsewhere, I will avoid presenting performance as a justification for
the change.

I’ve also added the patch to the commitfest. Thanks for the reminder.

--
With Regards,
Ashutosh Sharma.