I've put together some demos on PostgreSQL 10beta1.  Here's a few
feedback notes based on my experience with it.

Things I tested

* Logical replication pub/sub with replicating only two tables out of a
12-table FK heirarchy, including custom data types

* Partitioning a log-structured table, including a range type, exclusion
constraint, and foreign key.

* Various Parallel index queries on a 100m-row pgbench table

* Full text JSON search in a books database

* SCRAM authentication for local connections and replication

Positive changes beyond the obvious

* Yay defaults with replication on!

* Having defaults on the various _workers all devolve from max_workers
is also great.

* Constraint exclusion + partitioning Just Worked.


Q1. Why does wal_level default to "replica" and not "logical"?

Q2: I thought we were going to finally change the pg_dump default to
"custom" format in this release?  No?


P1. On the publishing node, logical replication relies on the *implied*
correspondence of the application_name and the replication_slot both
being named the same as the publication in order to associate a
particular publication with a particular replication connection.
However, there's absolutely nothing preventing me from also creating a
binary replication connection by the same name  It really seems like we
need a field in pg_stat_replication or pg_replication_slots which lists
the publication.

P2: If I create a subscription on a table with no primary key, I do not
recieve a warning.  There should be a warning, since in most cases such
a subscription will not work.  I suggest the text:

"logical replication target relation "public.fines" has no primary key.
Either create one, or set REPLICA IDENTITY index and set the published

P3: apparently jsonb_to_tsvector with lang parameter isn't immutable?
This means that it can't be used for indexing:

libdata=# create index bookdata_fts on bookdata using gin ((
ERROR:  functions in index expression must be marked IMMUTABLE

... and indeed it's not:

select proname, prosrc, proargtypes, provolatile from pg_proc where
proname = 'to_tsvector';
   proname   |         prosrc         | proargtypes | provolatile
 to_tsvector | jsonb_to_tsvector      | 3802        | s
 to_tsvector | to_tsvector_byid       | 3734 25     | i
 to_tsvector | to_tsvector            | 25          | s
 to_tsvector | json_to_tsvector       | 114         | s
 to_tsvector | jsonb_to_tsvector_byid | 3734 3802   | s
 to_tsvector | json_to_tsvector_byid  | 3734 114    | s

... can we fix that?

Josh Berkus
Containers & Databases Oh My!

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to