Thread: pgsql: Add wait_for_subscription_sync for TAP tests.
Add wait_for_subscription_sync for TAP tests.
The TAP tests for logical replication in src/test/subscription are using
the following code in many places to make sure that the subscription is
synchronized with the publisher:
$node_publisher->wait_for_catchup('tap_sub');
$node_subscriber->poll_query_until('postgres',
qq[SELECT count(1) = 0
FROM pg_subscription_rel
WHERE srsubstate NOT IN ('r', 's')]);
The new function wait_for_subscription_sync() can be used to replace the
above code. This eliminates duplicated code and makes it easier to write
future tests.
Author: Masahiko Sawada
Reviewed by: Amit Kapila, Shi yu
Discussion: https://postgr.es/m/CAD21AoC-fvAkaKHa4t1urupwL8xbAcWRePeETvshvy80f6WV1A@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/0c20dd33db1607d6a85ffce24238c1e55e384b49
Modified Files
--------------
src/test/perl/PostgreSQL/Test/Cluster.pm | 44 +++++++++++++++++++
src/test/subscription/t/001_rep_changes.pl | 18 ++------
src/test/subscription/t/002_types.pl | 7 +--
src/test/subscription/t/004_sync.pl | 18 +++-----
src/test/subscription/t/005_encoding.pl | 9 +---
src/test/subscription/t/006_rewrite.pl | 9 +---
src/test/subscription/t/007_ddl.pl | 9 +---
src/test/subscription/t/008_diff_schema.pl | 12 ++----
src/test/subscription/t/010_truncate.pl | 8 +---
src/test/subscription/t/011_generated.pl | 5 +--
src/test/subscription/t/013_partition.pl | 20 +++------
src/test/subscription/t/014_binary.pl | 5 +--
src/test/subscription/t/015_stream.pl | 9 +---
src/test/subscription/t/016_stream_subxact.pl | 9 +---
src/test/subscription/t/017_stream_ddl.pl | 9 +---
.../subscription/t/018_stream_subxact_abort.pl | 9 +---
.../subscription/t/019_stream_subxact_ddl_abort.pl | 9 +---
src/test/subscription/t/021_twophase.pl | 18 ++------
src/test/subscription/t/023_twophase_stream.pl | 10 +----
src/test/subscription/t/024_add_drop_pub.pl | 18 ++------
.../subscription/t/025_rep_changes_for_schema.pl | 18 +++-----
src/test/subscription/t/027_nosuperuser.pl | 9 +---
src/test/subscription/t/028_row_filter.pl | 19 ++------
src/test/subscription/t/029_on_error.pl | 5 +--
src/test/subscription/t/030_origin.pl | 19 ++------
src/test/subscription/t/031_column_list.pl | 50 ++++++++--------------
src/test/subscription/t/100_bugs.pl | 14 ++----
27 files changed, 129 insertions(+), 260 deletions(-)
On 2022-Aug-03, Amit Kapila wrote: > The new function wait_for_subscription_sync() can be used to replace the > above code. This eliminates duplicated code and makes it easier to write > future tests. Hmm, if you don't backpatch this, it might become a hurdle if we later backpatch tests that use it. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "I can see support will not be a problem. 10 out of 10." (Simon Wittber) (http://archives.postgresql.org/pgsql-general/2004-12/msg00159.php)
On Wed, Aug 3, 2022 at 4:15 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2022-Aug-03, Amit Kapila wrote: > > > The new function wait_for_subscription_sync() can be used to replace the > > above code. This eliminates duplicated code and makes it easier to write > > future tests. > > Hmm, if you don't backpatch this, it might become a hurdle if we later > backpatch tests that use it. > Yeah, that can happen for bug fixes but may not be a big problem as it just avoids duplicate code. If you and others want we can back this now or otherwise, we can do it later if we really see the difficulty later. -- With Regards, Amit Kapila.
Amit Kapila <amit.kapila16@gmail.com> writes:
> Yeah, that can happen for bug fixes but may not be a big problem as it
> just avoids duplicate code. If you and others want we can back this
> now or otherwise, we can do it later if we really see the difficulty
> later.
IMO we've seldom regretted back-patching testing infrastructure.
We have regretted not doing so.
regards, tom lane
On Wed, Aug 3, 2022 at 11:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapila16@gmail.com> writes: > > Yeah, that can happen for bug fixes but may not be a big problem as it > > just avoids duplicate code. If you and others want we can back this > > now or otherwise, we can do it later if we really see the difficulty > > later. > > IMO we've seldom regretted back-patching testing infrastructure. > We have regretted not doing so. Okay, I'll submit patches for backbranches to the original thread on -hackers. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/