postgres.git / summary / log / commit / refs

commit    3f2adace1ec025908b5189f0773b4eaab3d228d5
Author:   Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:     Wed Jul 17 17:24:28 2013 +0000
First released in: 9.4.0

    Fix end-of-loop optimization in pglz_find_match() function.
    
    After the recent pglz optimization patch, the next/prev pointers in the
    hash table are never NULL, INVALID_ENTRY_PTR is used to represent invalid
    entries instead. The end-of-loop check in pglz_find_match() function didn't
    get the memo. The result was the same from a correctness point of view, but
    because the NULL-check would never fail, the tiny optimization turned into
    a pessimization.
    
    Reported by Stephen Frost, using Coverity scanner.


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

diff --git a/src/backend/utils/adt/pg_lzcompress.c b/src/backend/utils/adt/pg_lzcompress.c
index ae6751929e3..1c129b800b3 100644
--- a/src/backend/utils/adt/pg_lzcompress.c
+++ b/src/backend/utils/adt/pg_lzcompress.c
@@ -466,7 +466,7 @@ pglz_find_match(int16 *hstart, const char *input, const char *end,
 		 * Be happy with lesser good matches the more entries we visited. But
 		 * no point in doing calculation if we're at end of list.
 		 */
-		if (hent)
+		if (hent != INVALID_ENTRY_PTR)
 		{
 			if (len >= good_match)
 				break;


[parent: 750f43685b1b]