From b63bea5fd3bba4d7a61c3beaba51a06f24b38da6 Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Mon, 7 Mar 2016 14:24:03 -0800 Subject: Further improvements to c8f621c43. Coverity and inspection for the issue addressed in fd45d16f found some questionable code. Specifically coverity noticed that the wrong length was added in ReorderBufferSerializeChange() - without immediate negative consequences as the variable isn't used afterwards. During code-review and testing I noticed that a bit of space was wasted when allocating tuple bufs in several places. Thirdly, the debug memset()s in ReorderBufferGetTupleBuf() reduce the error checking valgrind can do. Backpatch: 9.4, like c8f621c43. --- src/backend/replication/logical/reorderbuffer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'src/backend/replication/logical/reorderbuffer.c') diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c index e2ad4728cdc..f2b8f4b7b84 100644 --- a/src/backend/replication/logical/reorderbuffer.c +++ b/src/backend/replication/logical/reorderbuffer.c @@ -471,12 +471,15 @@ ReorderBufferGetTupleBuf(ReorderBuffer *rb, Size tuple_len) rb->nr_cached_tuplebufs--; tuple = slist_container(ReorderBufferTupleBuf, node, slist_pop_head_node(&rb->cached_tuplebufs)); + Assert(tuple->alloc_tuple_size == MaxHeapTupleSize); #ifdef USE_ASSERT_CHECKING memset(&tuple->tuple, 0xa9, sizeof(HeapTupleData)); + VALGRIND_MAKE_MEM_UNDEFINED(&tuple->tuple, sizeof(HeapTupleData)); #endif tuple->tuple.t_data = ReorderBufferTupleBufData(tuple); #ifdef USE_ASSERT_CHECKING memset(tuple->tuple.t_data, 0xa8, tuple->alloc_tuple_size); + VALGRIND_MAKE_MEM_UNDEFINED(tuple->tuple.t_data, tuple->alloc_tuple_size); #endif } else @@ -2152,7 +2155,7 @@ ReorderBufferSerializeChange(ReorderBuffer *rb, ReorderBufferTXN *txn, data += sizeof(HeapTupleData); memcpy(data, newtup->tuple.t_data, newlen); - data += oldlen; + data += newlen; } break; } -- cgit v1.2.3