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.patch
Improve 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
