postgres.git / summary / log / commit / refs

commit    aefb0a382c10877867d831afe8a292aa355c5a68
Author:   Peter Geoghegan <pg@bowt.ie>
Date:     Tue Jun 26 18:16:20 2018 +0000
First released in: 11.0

    Correct a comment on logtape.c's leader tape.
    
    randomAccess parallel tuplesorts are disallowed because the leader would
    try to write to its own leader tape, not because the leader would try to
    write to a worker tape directly.
    
    Cleanup from commit 9da0cc35284.


 src/backend/utils/sort/logtape.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backend/utils/sort/logtape.c b/src/backend/utils/sort/logtape.c
index a0d6c75c37e..62d7797e1e5 100644
--- a/src/backend/utils/sort/logtape.c
+++ b/src/backend/utils/sort/logtape.c
@@ -471,7 +471,7 @@ ltsConcatWorkerTapes(LogicalTapeSet *lts, TapeShare *shared,
 	 * Compute number of hole blocks so that we can later work backwards, and
 	 * instrument number of physical blocks.  We don't simply use physical
 	 * blocks directly for instrumentation because this would break if we ever
-	 * subsequently wrote to worker tape.
+	 * subsequently wrote to the leader tape.
 	 *
 	 * Working backwards like this keeps our options open.  If shared BufFiles
 	 * ever support being written to post-export, logtape.c can automatically


[parent: cdc2693a11b3]