| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | depesz(at)depesz(dot)com, Thom Brown <thom(at)linux(dot)com> |
| Cc: | 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 07:06:12 |
| Message-ID: | ee2fe0e07f8d4e9af696a9f7e254f46b6bf3b347.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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.
Yours,
Laurenz Albe
[1]: https://postgr.es/m/flat/19490-9c59c6a583513b99%40postgresql.org
| From | Date | Subject | |
|---|---|---|---|
| Next Message | hubert depesz lubaczewski | 2026-06-19 10:07:21 | Re: Why is WAL-file based replica stuck for long time (hour?) in IPC:RecoveryConflictSnapshot ? |
| Previous Message | KK CHN | 2026-06-19 05:54:08 | PgbackRest : backup command end: aborted with exception [101] |