On 2017-02-19 23:24, Erik Rijkers wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch 0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch 0003-Fix-after-trigger-execution-in-logical-replication-v2.patch 0004-Add-RENAME-support-for-PUBLICATIONs-and-SUBSCRIPTION-v2.patch 0001-Logical-replication-support-for-initial-data-copy-v4.patchImprove comment blocks in src/backend/replication/logical/snapbuild.c
[deep sigh...] attached...
--- src/backend/replication/logical/snapbuild.c.orig2 2017-02-19 17:25:57.237527107 +0100 +++ src/backend/replication/logical/snapbuild.c 2017-02-19 23:19:57.654946968 +0100 @@ -34,7 +34,7 @@ * xid. That is we keep a list of transactions between snapshot->(xmin, xmax) * that we consider committed, everything else is considered aborted/in * progress. That also allows us not to care about subtransactions before they - * have committed which means this modules, in contrast to HS, doesn't have to + * have committed which means this module, in contrast to HS, doesn't have to * care about suboverflowed subtransactions and similar. * * One complexity of doing this is that to e.g. handle mixed DDL/DML @@ -82,7 +82,7 @@ * Initially the machinery is in the START stage. When an xl_running_xacts * record is read that is sufficiently new (above the safe xmin horizon), * there's a state transition. If there were no running xacts when the - * runnign_xacts record was generated, we'll directly go into CONSISTENT + * running_xacts record was generated, we'll directly go into CONSISTENT * state, otherwise we'll switch to the FULL_SNAPSHOT state. Having a full * snapshot means that all transactions that start henceforth can be decoded * in their entirety, but transactions that started previously can't. In @@ -274,7 +274,7 @@ /* * Allocate a new snapshot builder. * - * xmin_horizon is the xid >=which we can be sure no catalog rows have been + * xmin_horizon is the xid >= which we can be sure no catalog rows have been * removed, start_lsn is the LSN >= we want to replay commits. */ SnapBuild * @@ -1642,7 +1642,7 @@ fsync_fname("pg_logical/snapshots", true); /* - * Now there's no way we can loose the dumped state anymore, remember this + * Now there's no way we can lose the dumped state anymore, remember this * as a serialization point. */ builder->last_serialized_snapshot = lsn; @@ -1858,7 +1858,7 @@ char path[MAXPGPATH]; /* - * We start of with a minimum of the last redo pointer. No new replication + * We start off with a minimum of the last redo pointer. No new replication * slot will start before that, so that's a safe upper bound for removal. */ redo = GetRedoRecPtr(); @@ -1916,7 +1916,7 @@ /* * It's not particularly harmful, though strange, if we can't * remove the file here. Don't prevent the checkpoint from - * completing, that'd be cure worse than the disease. + * completing, that'd be a cure worse than the disease. */ if (unlink(path) < 0) {
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers