Update docs for 2pc

Author: levkk

docs/features/sharding/cross-shard.md

@@ -15,7 +15,7 @@ While this works for simple queries, others that involve sorting or aggregation
 
 ## Sorting
 
-If the client requests results to be ordered by one or more columns, PgDog can interpret this request and perform the sorting once it receives all data messages from all servers. For queries that span multiple shards, this feature allows to retrieve results in the correct order. For example:
+If the client requests results to be ordered by one or more columns, PgDog can interpret this request and perform the sorting once it receives all data messages from all servers. For queries that span multiple shards, this feature allows you to retrieve results in the correct order. For example:
 
 ```postgresql
 SELECT * FROM users WHERE admin IS true
@@ -71,13 +71,12 @@ DDL statements, i.e., queries that modify the database schema, like `CREATE TABL
 
 This assumes that all shards in the cluster have an identical schema. This is typically desired to make management of sharded databases simpler, but in scenarios where this is not possible, DDL queries can always be routed to specific shards using [manual routing](manual-routing.md).
 
-!!! note
-    PgDog doesn't use two-phase commit so make sure your DDL
-    statements are idempotent and can be retried in case of an error.
+If [two-phase commit](2pc.md) is enabled, DDL statements have a high chance to be atomic. Alternatively, they can generally be written to be idempotent and safe to retry in case of error.
 
 ### Two-phase commit
 
-Currently, PgDog doesn't use two-phase commit to synchronize changes across all shards. Support for this feature is currently being built, and will require database operators to enable [prepared transactions](https://www.postgresql.org/docs/current/sql-prepare-transaction.html).
+PgDog supports Postgres' [prepared transactions](https://www.postgresql.org/docs/current/sql-prepare-transaction.html) and [two-phase commit](2pc.md). If enabled, cross-shard writes have a high chance to be atomic and eventually consistent.
+
 
 ## Aggregates
 

docs/features/sharding/omnishards.md

@@ -19,14 +19,16 @@ tables = [
 ]
 ```
 
-## Query router
+## Query routing
 
 Omnisharded tables are treated differently by the query router. Write queries are sent to all shards concurrently, while read queries are distributed evenly between shards using round robin.
 
 If the query contains a sharding key, it will be used instead, and omnisharded tables in that query will be ignored.
 
 ### Consistency
 
-Writing data to omnisharded tables is not currently atomic. While we work on adding support for two-phase commit, make sure writes to omni tables can be repeated in case of failure. This can be done with unique indexes and `ON CONFLICT ... DO UPDATE` queries.
+Writing data to omnisharded tables is atomic if you enabled [two-phase commit](2pc.md).
 
-Reads from omni tables are routed to individual shards. If you update data in those tables at the same time, `SELECT` queries to these tables may return different results for a brief period of time.
+If you can't or choose not to use 2pc, make sure writes to omnisharded tables can be repeated in case of failure. This can be achieved by using unique indexes and `INSERT ... ON CONFLICT ... DO UPDATE` queries.
+
+Since reads from omnisharded tables are routed to individual shards, while two-phase commit takes place, queries to these tables may return different results for a brief period of time.

docs/features/sharding/supported-queries.md

@@ -5,8 +5,8 @@
 Postgres has 3 kinds of queries, each handled a little bit differently in a sharded context:
 
 1. CRUD statements (`INSERT`, `UPDATE`, `SELECT`, `DELETE`, `COPY`) are parsed for sharding keys and routed to one or more shards
-5. DDL statements (e.g., `CREATE TABLE`, `BEGIN`, `ROLLBACK`, etc.) are sent to all shards in parallel
-6. `SET` statements are intercepted and client state is updated to keep track of session variables
+2. DDL statements (e.g., `CREATE TABLE`, `BEGIN`, `ROLLBACK`, etc.) are sent to all shards in parallel
+3. `SET` statements are intercepted and client state is updated to keep track of session variables
 
 ## CRUD
 
@@ -20,14 +20,14 @@ Postgres has 3 kinds of queries, each handled a little bit differently in a shar
 #### Examples
 
 ```postgresql
--- Sharding key equals to a single value
+-- Sharding key equals a single value
 SELECT * FROM users WHERE user_id = $1
 
 -- Sharding keys IN tuple
 SELECT * FROM users WHERE id IN ($1, $2, $3)
 ```
 
-Queries that don't match this pattern presently will be routed to all shards. We are continuously adding support for more complex patterns.
+Queries that don't match this pattern will currently be routed to all shards. We are continuously adding support for more complex patterns.
 
 #### `SELECT` queries that write
 
@@ -72,4 +72,4 @@ Currently, PgDog only supports `INSERT` statements with one tuple in the `VALUES
 
 ## DDL
 
-DDL statements are sent to all shards in parallel. Currently, PgDog doesn't use 2-phase commit so consider using idempotent schema changes to guarantee consistency across shards.
+DDL statements (e.g., `CREATE TABLE`) are sent to all shards in parallel. If [two-phase commit](2pc.md) is enabled, DDL statements have a high chance to be atomic.