-- ===================================================================
-- test shard repair functionality
-- ===================================================================

-- create a table and create its distribution metadata
CREATE TABLE customer_engagements ( id integer, created_at date, event_data text );

-- add some indexes
CREATE INDEX ON customer_engagements (id);
CREATE INDEX ON customer_engagements (created_at);
CREATE INDEX ON customer_engagements (event_data);

INSERT INTO pgs_distribution_metadata.partition (relation_id, partition_method, key)
VALUES
	('customer_engagements'::regclass, 'h', 'id');

INSERT INTO pgs_distribution_metadata.shard
	(id, relation_id, storage, min_value, max_value)
VALUES
	(20, 'customer_engagements'::regclass, 't', '-2147483648', '2147483647');

-- Note we are "distributing" this table on localhost and 127.0.0.1, i.e. two
-- hostnames for the same machine. This is a hack to get the pg_shard master to
-- connect back to itself (most we can hope for with installcheck). The other
-- entries are to test input parameter validation.
INSERT INTO pgs_distribution_metadata.shard_placement
	(id, node_name, node_port, shard_id, shard_state)
VALUES
	(200, 'localhost', $PGPORT, 20, 1),
	(201, '127.0.0.1', $PGPORT, 20, 3),
	(202, 'dummyhost', $PGPORT, 20, 1),
	(203, 'otherhost', $PGPORT, 20, 3);

-- first, test input checking by trying to copy into a finalized placement
SELECT master_copy_shard_placement(20, 'localhost', $PGPORT, 'dummyhost', $PGPORT);

-- also try to copy from an inactive placement
SELECT master_copy_shard_placement(20, 'otherhost', $PGPORT, '127.0.0.1', $PGPORT);

-- next, create an empty "shard" for the table
CREATE TABLE customer_engagements_20 ( LIKE customer_engagements );

-- capture its current object identifier
\o /dev/null
SELECT 'customer_engagements_20'::regclass::oid AS shardoid;
\gset
\o

-- "copy" this shard from localhost to 127.0.0.1
SELECT master_copy_shard_placement(20, 'localhost', $PGPORT, '127.0.0.1', $PGPORT);

-- the table was recreated, so capture the new object identifier
\o /dev/null
SELECT 'customer_engagements_20'::regclass::oid AS repairedoid;
\gset
\o

-- the recreated table should have a new oid
SELECT :shardoid != :repairedoid AS shard_recreated; 

-- now do the same test over again with a foreign table
CREATE FOREIGN TABLE remote_engagements (
	id integer,
	created_at date,
	event_data text
) SERVER fake_fdw_server;

INSERT INTO pgs_distribution_metadata.partition (relation_id, partition_method, key)
VALUES
	('remote_engagements'::regclass, 'h', 'id');

INSERT INTO pgs_distribution_metadata.shard
	(id, relation_id, storage, min_value, max_value)
VALUES
	(30, 'remote_engagements'::regclass, 'f', '-2147483648', '2147483647');

INSERT INTO pgs_distribution_metadata.shard_placement
	(id, node_name, node_port, shard_id, shard_state)
VALUES
	(300, 'localhost', $PGPORT, 30, 1),
	(301, '127.0.0.1', $PGPORT, 30, 3);

CREATE FOREIGN TABLE remote_engagements_30 (
	id integer,
	created_at date,
	event_data text
) SERVER fake_fdw_server;

-- oops! we don't support repairing shards backed by foreign tables
SELECT master_copy_shard_placement(30, 'localhost', $PGPORT, '127.0.0.1', $PGPORT);

-- At this point, we've tested recreating a shard's table, but haven't seen
-- whether the rows themselves are correctly copied. We'll insert a few rows
-- into our "shard" and use our hack to get the pg_shard worker to connect back
-- to itself and copy the rows back into their own shard, i.e. doubling rows.
INSERT INTO customer_engagements_20 DEFAULT VALUES;

-- call the copy UDF directly to just copy the rows without recreating table
SELECT worker_copy_shard_placement('customer_engagements_20', 'localhost', $PGPORT);

-- should expect twice as many rows as we put in
SELECT COUNT(*) FROM customer_engagements_20;