Here are some review comments for patch v12-0001 (test code only)
======
src/test/subscription/t/014_binary.pl
# Check the synced data on subscribers
~
There are a couple of comments like the above that say: "on
subscribers" instead of "on subscriber".
~~~
I wondered if it might be useful to also include another test case
that demonstrates you can still use COPY with binary format even when
the table column orders are different, so long as the same names have
the same data types. In other words, it shows apparently, the binary
row COPY processes per column; not one single binary data copy
spanning all the replicated columns.
For example,
# --------------------------------
# Test syncing tables with different column order
$node_publisher->safe_psql(
'postgres', qq(
CREATE TABLE public.test_col_order (
a bigint, b int
);
INSERT INTO public.test_col_order (a,b)
VALUES (1,2),(3,4);
));
$node_subscriber->safe_psql(
'postgres', qq(
CREATE TABLE public.test_col_order (
b int, a bigint
);
ALTER SUBSCRIPTION tsub REFRESH PUBLICATION;
));
# Ensure nodes are in sync with each other
$node_subscriber->wait_for_subscription_sync($node_publisher, 'tsub');
# Check the synced data on subscribers
$result = $node_subscriber->safe_psql('postgres', 'SELECT a,b FROM
public.test_col_order;');
is( $result, '1|2
3|4', 'check synced data on subscriber for different column order and
binary = true');
# --------------------------------
------
Kind Regards,
Peter Smith.
Fujitsu Australia
