Tomas Vondra <tomas.von...@enterprisedb.com> writes:
> I can reproduce it on my system (rpi4 running 32-bit raspbian).
Yeah, more or less same as what I'm testing on.
Seeing that the complaint is about pfree'ing a non-maxaligned
ReorderBufferChange pointer, I tried adding
diff --git a/src/backend/replication/logical/reorderbuffer.c
b/src/backend/replication/logical/reorderbuffer.c
index 89cf9f9389..dfa9b6c9ee 100644
--- a/src/backend/replication/logical/reorderbuffer.c
+++ b/src/backend/replication/logical/reorderbuffer.c
@@ -472,6 +472,8 @@ ReorderBufferGetChange(ReorderBuffer *rb)
change = (ReorderBufferChange *)
MemoryContextAlloc(rb->change_context,
sizeof(ReorderBufferChange));
+ Assert(change == (void *) MAXALIGN(change));
+
memset(change, 0, sizeof(ReorderBufferChange));
return change;
}
and this failed!
(gdb) f 3
#3 0x003cb888 in ReorderBufferGetChange (rb=0x24ed820) at reorderbuffer.c:475
475 Assert(change == (void *) MAXALIGN(change));
(gdb) p change
$1 = (ReorderBufferChange *) 0x24aaa14
So the bug is in fact in David's changes, and it consists in palloc
sometimes handing back non-maxaligned pointers. I find it mildly
astonishing that we managed to get through core regression tests
without such a fault surfacing, but there you have it.
This machine has MAXALIGN 8 but 4-byte pointers, so there's something
wrong with that situation.
regards, tom lane
