Re: pglogical_output - a general purpose logical decoding output plugin - Mailing list pgsql-hackers

From Tomasz Rybak
Subject Re: pglogical_output - a general purpose logical decoding output plugin
Date
Msg-id 20160103182109.2558.89751.pgcf@coridan.postgresql.org
Whole thread Raw
In response to Re: pglogical_output - a general purpose logical decoding output plugin  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: pglogical_output - a general purpose logical decoding output plugin
List pgsql-hackers
The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:       not tested
Spec compliant:           not tested
Documentation:            tested, failed

Applies cleanly on current master (b416c0bb622ce5d33fdbec3bbce00451132f10ec).

Builds without any problems on current Debian unstable (am64 arch, GCC 5.3.1-4, glibc 2.21-6)
There are 2 errors in tests, but they also occur on trunk build.
parallel group (20 tests):  json_encoding combocid portals_p2 advisory_lock tsdicts xmlmap equivclass guc
functional_depsdependency json select_views cluster tsearch window jsonb indirect_toast bitmapops foreign_key
foreign_data   select_views             ... FAILED    portals_p2               ... ok
 
parallel group (2 tests):  create_view create_index    create_index             ... FAILED    create_view
...ok
 

README.md:
+Only one database is replicated, rather than the whole PostgreSQL install. A
[...]
+Unlike block-level ("physical") streaming replication, the change stream from
+the `pglogical` output plugin is compatible across different PostgreSQL
+versions and can even be consumed by non-PostgreSQL clients.
+
+Because logical decoding is used, only the changed rows are sent on the wire.
+There's no index change data, no vacuum activity, etc transmitted.
+
+The use of a replication slot means that the change stream is reliable and
+crash-safe. If

Isn't it feature of logical replication, not this particular plugin?
I'm not sure whether all that text needs to be repeated here.
OTOH this is good summary - so maybe just add links to base
documentation about replication, logical replication, slots, etc.

+# Usage
+
+The overall flow of client/server interaction is:
This part (flow) belongs to DESIGN.md, not to usage.

+* [Client issues `IDENTIFY_SYSTEM`
Is the [ needed here?

protocol.txt
Contains wrapped lines, but also very long lines. While long
lines make sense for tables, they should not occur in paragraphs, e.g. in
+== Arguments client supplies to output plugin
and following ones. It looks like parts of this file were formatted, and parts not.

In summary, documentation is mostly OK, and it describe plugin quite nicely.
The only thing I haven't fully understood is COPY-related - so it might be
good to extend a bit. And how COPY relates to JSON output format?

pglogical_output_plhooks.c
+#if PG_VERSION_NUM >= 90500
+        username = GetUserNameFromId(GetUserId(), false);
+#else
+        username = GetUserNameFromId(GetUserId());
+#endif

Is it needed? I mean - will tris module compiled for 9.4 (or earlier)
versions, or will it be 9.5 (or even 9.6)+ only?

pglogical_output.c
+        /*
+         * Will we forward changesets? We have to if we're on 9.4;
+         * otherwise honour the client's request.
+         */
+        if (PG_VERSION_NUM/100 == 904)
+        {
+            /*
+             * 9.4 unconditionally forwards changesets due to lack of
+             * replication origins, and it can't ever send origin info
+             * for the same reason.
+             */

Similar case. In mail from 2015-11-12 (path v2) you removed v9.4 compatibility,
so I'm not sure whether checking for 9.4 or 9.5 makes any sense now.

This review focuses mostly on documentation, but I went through both
documentation and code. I understood most of the code (and it makes
sense after some cosideration :-) ), but I'm not proficient in PostgreSQL
to be fully sure that there are no hidden bugs.
At the same time - I haven't seen problems and suspicious fragments of code,
so after fixing mentioned problems it should go to the commiter.

Best regards.


The new status of this patch is: Waiting on Author



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Some 9.5beta2 backend processes not terminating properly?
Next
From: Tom Lane
Date:
Subject: Re: Some 9.5beta2 backend processes not terminating properly?