v2.18.1: Add retries on shard activation; fix race condition in shards activation; support full host:port/db format in microsharding_migration_after()

Author: dimikot

README.md

@@ -297,7 +297,13 @@ export const cluster = new Cluster({
 
 ### Microsharding Debug Views
 
-The `microsharding_migration_after()` function creates so-called "debug views" for each sharded table in your cluster. For instance, it you have `sh0001.users`, `sh0002.users` etc. tables. then it will create a debug view `public.users` with the definition like:
+The `microsharding_migration_after()` function creates so-called "debug views" for each sharded table in your cluster:
+
+```sql
+SELECT microsharding.microsharding_migration_after();
+```
+
+For instance, it you have `sh0001.users`, `sh0002.users` etc. tables, then it will create a debug view `public.users` with the definition like:
 
 ```sql
 -- This is what pg-microsharding creates automatically.
@@ -309,9 +315,13 @@ CREATE VIEW public.users AS
   ...;
 ```
 
-Even more, if you pass the list of all PostgreSQL hosts, and those hosts can access each other without a password (e.g. they have  `/var/lib/postgresql/N/.pgpass` files), then those debug views will work **across all shards on all nodes, including the remote ones** (using [foreign-data wrapper](https://www.postgresql.org/docs/current/postgres-fdw.html) functionality).
+Even more, if you pass the list of all PostgreSQL hosts, and those hosts can access each other without a password (e.g. they have  `/var/lib/postgresql/N/.pgpass` files), then those debug views will work **across all shards on all nodes, including the remote ones** (using [foreign-data wrapper](https://www.postgresql.org/docs/current/postgres-fdw.html) functionality):
 
-So **for debugging purposes**, you'll be able to run queries across all microshards in your `psql` sessions. This is typically very convenient.
+```sql
+SELECT microsharding.microsharding_migration_after('host1,host2,host3');
+```
+
+So **for debugging purposes**, you'll be able to run queries _across all microshards on all hosts_ in your `psql` sessions.
 
 Of course those **debug views are not suitable for production traffic**: cross-node communication in PostgreSQL, as well as query planning, work not enough inefficiently. Do not even try, use application-level microshards routing, like e.g. [Ent Framework](https://ent-framework.org/) provides.
 
@@ -324,6 +334,12 @@ postgres=# SELECT shard, email FROM users
 -- debugging purposes only.
 ```
 
-As of `microsharding_migration_before()`, you must call it before any changes are applied to your microsharded tables. The function drops all of the debug views mentioned above. E.g. if you remove a column from a table, PostgreSQL would not allow you to do it it this column is mentioned in any of the views, so it's important to drop the views and re-create them afterwards.
+As of `microsharding_migration_before()`, you must call it before any changes are applied to your microsharded tables:
+
+```sql
+SELECT microsharding.microsharding_migration_before();
+```
+
+The function drops all of the debug views mentioned above. E.g. if you remove a column from a table, PostgreSQL would not allow you to do it it this column is mentioned in any of the views, so it's important to drop the views and re-create them afterwards.
 
 Typically, you just call `microsharding_migration_before()` in your pre-migration sequence and then call `microsharding_migration_after()` in your post-migration steps.

docs/README.md

@@ -301,7 +301,13 @@ export const cluster = new Cluster({
 
 ### Microsharding Debug Views
 
-The `microsharding_migration_after()` function creates so-called "debug views" for each sharded table in your cluster. For instance, it you have `sh0001.users`, `sh0002.users` etc. tables. then it will create a debug view `public.users` with the definition like:
+The `microsharding_migration_after()` function creates so-called "debug views" for each sharded table in your cluster:
+
+```sql
+SELECT microsharding.microsharding_migration_after();
+```
+
+For instance, it you have `sh0001.users`, `sh0002.users` etc. tables, then it will create a debug view `public.users` with the definition like:
 
 ```sql
 -- This is what pg-microsharding creates automatically.
@@ -313,9 +319,13 @@ CREATE VIEW public.users AS
   ...;
 ```
 
-Even more, if you pass the list of all PostgreSQL hosts, and those hosts can access each other without a password (e.g. they have  `/var/lib/postgresql/N/.pgpass` files), then those debug views will work **across all shards on all nodes, including the remote ones** (using [foreign-data wrapper](https://www.postgresql.org/docs/current/postgres-fdw.html) functionality).
+Even more, if you pass the list of all PostgreSQL hosts, and those hosts can access each other without a password (e.g. they have  `/var/lib/postgresql/N/.pgpass` files), then those debug views will work **across all shards on all nodes, including the remote ones** (using [foreign-data wrapper](https://www.postgresql.org/docs/current/postgres-fdw.html) functionality):
 
-So **for debugging purposes**, you'll be able to run queries across all microshards in your `psql` sessions. This is typically very convenient.
+```sql
+SELECT microsharding.microsharding_migration_after('host1,host2,host3');
+```
+
+So **for debugging purposes**, you'll be able to run queries _across all microshards on all hosts_ in your `psql` sessions.
 
 Of course those **debug views are not suitable for production traffic**: cross-node communication in PostgreSQL, as well as query planning, work not enough inefficiently. Do not even try, use application-level microshards routing, like e.g. [Ent Framework](https://ent-framework.org/) provides.
 
@@ -328,6 +338,12 @@ postgres=# SELECT shard, email FROM users
 -- debugging purposes only.
 ```
 
-As of `microsharding_migration_before()`, you must call it before any changes are applied to your microsharded tables. The function drops all of the debug views mentioned above. E.g. if you remove a column from a table, PostgreSQL would not allow you to do it it this column is mentioned in any of the views, so it's important to drop the views and re-create them afterwards.
+As of `microsharding_migration_before()`, you must call it before any changes are applied to your microsharded tables:
+
+```sql
+SELECT microsharding.microsharding_migration_before();
+```
+
+The function drops all of the debug views mentioned above. E.g. if you remove a column from a table, PostgreSQL would not allow you to do it it this column is mentioned in any of the views, so it's important to drop the views and re-create them afterwards.
 
 Typically, you just call `microsharding_migration_before()` in your pre-migration sequence and then call `microsharding_migration_after()` in your post-migration steps.

docs/functions/move.md

@@ -8,7 +8,7 @@
 
 > **move**(`__namedParameters`): `Promise`\<`void`\>
 
-Defined in: [src/api/move.ts:26](https://github.com/clickup/pg-microsharding/blob/master/src/api/move.ts#L26)
+Defined in: [src/api/move.ts:27](https://github.com/clickup/pg-microsharding/blob/master/src/api/move.ts#L27)
 
 Moves a shard from one master DB to another.