Fix typo in reorderbuffer.c.
authorAmit Kapila <[email protected]>
Tue, 5 Jan 2021 02:26:40 +0000 (07:56 +0530)
committerAmit Kapila <[email protected]>
Tue, 5 Jan 2021 02:26:40 +0000 (07:56 +0530)
Author: Zhijie Hou
Reviewed-by: Sawada Masahiko
Discussion: https://postgr.es/m/ba88bb58aaf14284abca16aec04bf279@G08CNEXMBPEKD05.g08.fujitsu.local

src/backend/replication/logical/reorderbuffer.c

index 315bfe7cae27f46dbc25a3b65421a52c3807d7da..5a62ab8bbc1ac98a6b862050011299e92f71ccaa 100644 (file)
@@ -2119,13 +2119,13 @@ ReorderBufferProcessTXN(ReorderBuffer *rb, ReorderBufferTXN *txn,
                     * Mapped catalog tuple without data, emitted while
                     * catalog table was in the process of being rewritten. We
                     * can fail to look up the relfilenode, because the
-                    * relmapper has no "historic" view, in contrast to normal
-                    * the normal catalog during decoding. Thus repeated
-                    * rewrites can cause a lookup failure. That's OK because
-                    * we do not decode catalog changes anyway. Normally such
-                    * tuples would be skipped over below, but we can't
-                    * identify whether the table should be logically logged
-                    * without mapping the relfilenode to the oid.
+                    * relmapper has no "historic" view, in contrast to the
+                    * normal catalog during decoding. Thus repeated rewrites
+                    * can cause a lookup failure. That's OK because we do not
+                    * decode catalog changes anyway. Normally such tuples
+                    * would be skipped over below, but we can't identify
+                    * whether the table should be logically logged without
+                    * mapping the relfilenode to the oid.
                     */
                    if (reloid == InvalidOid &&
                        change->data.tp.newtuple == NULL &&