On Tue, Apr 23, 2024 at 11:49 AM vignesh C wrote:
>
> On Sat, 20 Apr 2024 at 10:30, Alexander Lakhin wrote:
> >
> > Hello Michael and Robert,
> >
> > 20.04.2024 05:57, Michael Paquier wrote:
> > > On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote:
> > >> It looks to me like in the
On Sat, 20 Apr 2024 at 10:30, Alexander Lakhin wrote:
>
> Hello Michael and Robert,
>
> 20.04.2024 05:57, Michael Paquier wrote:
> > On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote:
> >> It looks to me like in the first run it took 3 minutes for the
> >> replay_lsn to catch up to the
Hi,
On 2024-04-19 13:57:41 -0400, Robert Haas wrote:
> Have others seen this? Is there something we can/should do about it?
Yes, I've also seen this - but never quite reproducible enough to properly
tackle it.
The first thing I'd like to do is to make the wait_for_catchup routine
regularly log
Hello Michael and Robert,
20.04.2024 05:57, Michael Paquier wrote:
On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote:
It looks to me like in the first run it took 3 minutes for the
replay_lsn to catch up to the desired value, and in the second run,
two seconds. I think I have seen
On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote:
> It looks to me like in the first run it took 3 minutes for the
> replay_lsn to catch up to the desired value, and in the second run,
> two seconds. I think I have seen previous instances where something
> similar happened, although in