On Sun, Aug 15, 2021 at 8:16 PM Michael Paquier wrote:
>
> On Fri, Aug 13, 2021 at 05:59:21PM -0700, Soumyadeep Chakraborty wrote:
> > and passes with the code change, as expected. I can't explain why the
> > test doesn't freeze up in v3 in wait_for_catchup() at the end.
>
> It took me some some t
On Fri, Aug 13, 2021 at 05:59:21PM -0700, Soumyadeep Chakraborty wrote:
> and passes with the code change, as expected. I can't explain why the
> test doesn't freeze up in v3 in wait_for_catchup() at the end.
It took me some some to understand why. If I am right, that's because
of the intermediat
Hey Michael,
Really appreciate the review!
On Wed, Aug 11, 2021 at 12:40 AM Michael Paquier wrote:
> Agreed that the current behavior is confusing. As you are using the
> commit timestamp for the comparison, this is right. One small-ish
> comment I have about the code is that we should mentio
On Fri, Aug 06, 2021 at 04:59:55PM -0700, Soumyadeep Chakraborty wrote:
> Rebased. Also added a stronger check to see if the standby is stuck in
> recovery_min_apply_delay:
>
> $node_standby->poll_query_until('postgres', qq{
> SELECT wait_event = 'RecoveryApplyDelay' FROM pg_stat_activity
> WHERE
Rebased. Also added a stronger check to see if the standby is stuck in
recovery_min_apply_delay:
$node_standby->poll_query_until('postgres', qq{
SELECT wait_event = 'RecoveryApplyDelay' FROM pg_stat_activity
WHERE backend_type='startup';
}) or die "Timed out checking if startup is in recovery_min_
Hi Kyotaro,
Thanks for the review!
On Mon, Aug 2, 2021 at 11:42 PM Kyotaro Horiguchi
wrote:
> One comment from me.
>
> +$node_standby->safe_psql('postgres', "ALTER SYSTEM SET
> recovery_min_apply_delay TO 0;");
>
> It might be better do "SET reco.. TO DEFAULT" instead.
>
Sure.
> And how abou
At Mon, 2 Aug 2021 22:21:56 -0700, Soumyadeep Chakraborty
wrote in
> Hello,
>
> I came across this issue while I was tweaking a TAP test with Ashwin for
> this thread [1].
>
> We noticed that while the startup process waits for a recovery delay, it does
> not respect changes to the recovery_mi
Hello,
I came across this issue while I was tweaking a TAP test with Ashwin for
this thread [1].
We noticed that while the startup process waits for a recovery delay, it does
not respect changes to the recovery_min_apply_delay GUC. So:
// Standby is waiting on recoveryWakeupLatch with a large
re
