On Thu, 12 Dec 2019 at 14:18, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Dec 12, 2019 at 11:53 AM Amit Khandekar <amitdkhan...@gmail.com> > wrote: > > > > On Thu, 12 Dec 2019 at 11:34, Amit Khandekar <amitdkhan...@gmail.com> wrote: > > > > > So max_changes_in_memory is the one > > > that allows us to reduce the number of transactions required, so we > > > can cut down on the outer loop iterations and make the test finish > > > much earlier. > > > > > > > > But also note that, we can't use the test suite in > > > contrib/test_decoding, because max_changes_in_memory needs server > > > restart. So we need to shift this test to src/test/recovery. And > > > there, I guess it is not that critical for the testcase to be very > > > quick because the tests in general are much slower than the ones in > > > contrib/test_decoding, although it would be nice to make it fast. What > > > I propose is to modify max_changes_in_memory, do a server restart > > > (which takes hardly a sec), run the testcase (3.5 sec) and then > > > restart after resetting the guc. So totally it will be around 4-5 > > > seconds. > > > > Sorry I meant max_files_per_process. > > > > Okay, what time other individual tests take in that directory on your > machine? For src/test/recovery directory, on average, a test takes about 4-5 seconds.
> How about providing a separate test patch for this case so > that I can also test it? Attached is a v4 patch that also addresses your code comments so far. I have included the test case in 006_logical_decoding.pl. I observed that the test case just adds only about 0.5 to 1 sec time. Please verify on your env also, and also whether the test reproduces the issue without the code changes. > I think we can take the opinion of others as > well if they are fine with adding this test, otherwise, we can go > ahead with the main patch. Sure. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company
use_vfd_for_logrep_v4.patch
Description: Binary data
