Re: Address the bug in 041_checkpoint_at_promote.pl

2025-02-13 Thread Nitin Jadhav
> > Anyway, how did you find that? Did you see a pattern when running the > > test on a very slow machine or just from a read? That was a good > > catch. > +1. I was wondering the same. I was writing a TAP test to reproduce a crash recovery issue and used parts of 041_checkpoint_at_promote.pl. U

Re: Address the bug in 041_checkpoint_at_promote.pl

2025-02-12 Thread Ashutosh Bapat
On Thu, Feb 13, 2025 at 5:08 AM Michael Paquier wrote: > > Anyway, how did you find that? Did you see a pattern when running the > test on a very slow machine or just from a read? That was a good > catch. +1. I was wondering the same. -- Best Wishes, Ashutosh Bapat

Re: Address the bug in 041_checkpoint_at_promote.pl

2025-02-12 Thread Michael Paquier
On Wed, Feb 12, 2025 at 04:50:34PM +0530, Nitin Jadhav wrote: > I see that it's already been committed and understand that no other > changes are needed. Thank you! My apologies for the lack of updates here. I've looked at the whole test again yesterday and the issue that you have reported was th

Re: Address the bug in 041_checkpoint_at_promote.pl

2025-02-12 Thread Nitin Jadhav
> > Removing the wakeup makes the test > > complete, but it should wait in its lookup loop. > > Thank you for confirming. Besides fixing the if condition as done in > the patch, do you think any other changes are necessary? I see that it's already been committed and understand that no other change

Re: Address the bug in 041_checkpoint_at_promote.pl

2025-02-12 Thread Nitin Jadhav
> Removing the wakeup makes the test > complete, but it should wait in its lookup loop. Thank you for confirming. Besides fixing the if condition as done in the patch, do you think any other changes are necessary? Best Regards, Nitin Jadhav Azure Database for PostgreSQL Microsoft On Wed, Feb 12,

Re: Address the bug in 041_checkpoint_at_promote.pl

2025-02-12 Thread Michael Paquier
On Wed, Feb 12, 2025 at 01:28:55PM +0530, Nitin Jadhav wrote: > The code is intended to wait for the restart point to complete before > proceeding. However, it doesn't actually wait. Regardless of whether > the restart point completes, the loop exits after the first iteration > because the if condi

Address the bug in 041_checkpoint_at_promote.pl

2025-02-11 Thread Nitin Jadhav
While testing, I discovered an issue in 041_checkpoint_at_promote.pl. # Wait until the previous restart point completes on the newly-promoted # standby, checking the logs for that. my $checkpoint_complete = 0; foreach my $i (0 .. 10 * $PostgreSQL::Test::Utils::timeout_default) { if ($node_stan