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
I just did a run of the regression test where this test was the last
one to finish by quite a lot. Key log entries:
[13:35:48.583](0.039s) # initializing database system by copying initdb template
...
[13:35:52.397](0.108s) ok 5 - Check reset timestamp for
'test_tab1_sub' is newer after second
