Re: Why is WAL-file based replica stuck for long time (hour?) in IPC:RecoveryConflictSnapshot ?

From: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Thom Brown <thom(at)linux(dot)com>, pgsql-general mailing list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Why is WAL-file based replica stuck for long time (hour?) in IPC:RecoveryConflictSnapshot ?
Date: 2026-06-19 10:07:21
Message-ID: ajUU2WfSbZb5QXQN@depesz.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Jun 19, 2026 at 09:06:12AM +0200, Laurenz Albe wrote:
> On Thu, 2026-06-18 at 15:33 +0200, hubert depesz lubaczewski wrote:
> > On Thu, Jun 18, 2026 at 02:07:36PM +0100, Thom Brown wrote:
> > > Have you got anything in the logs that say "conflict with recovery"?
> > > Also, I know you are just running count(*), but is there a transaction
> > > being left open?
> > > SELECT pid, state, xact_start, query
> > > FROM pg_stat_activity
> > > ORDER BY xact_start NULLS LAST;
> > > Any 'idle in transaction' for too long?
> > > What is max_standby_streaming_delay and hot_standby_feedback set to?
> >
> > No transactions were happening then. These are our "Disaster Recovery"
> > instances, and they are generally unused.
> >
> > max_standby_streaming_delay is 10 minutes
> > hot_standby_feedback is on.
> >
> > Please note that these are *NOT* doing streaming replication!
>
> Could it be bug #19490 [1]?
> That would be fixed in the next minor releases.

Maybe it's related, but there are two issues:
1. it's not streaming replication
2. waitevent/type doesn't match. in my case it's
IPC/RecoveryConflictSnapshot

Best regards,

depesz

In response to

Browse pgsql-general by date

  From Date Subject
Next Message KK CHN 2026-06-19 12:06:12 Can use NFS mount partition for Pgbackrest Repo -path ?
Previous Message Laurenz Albe 2026-06-19 07:06:12 Re: Why is WAL-file based replica stuck for long time (hour?) in IPC:RecoveryConflictSnapshot ?