You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

Tom Lane 6a3d3965d6 Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms. ... When re-reading an update involving both an old tuple and a new tuple from disk, reorderbuffer.c was careless about whether the new tuple is suitably aligned for direct access --- in general, it isn't. We'd missed seeing this in the buildfarm because the contrib/test_decoding tests exercise this code path only a few times, and by chance all of those cases have old tuples with length a multiple of 4, which is usually enough to make the access to the new tuple's t_len safe. For some still-not-entirely-clear reason, however, Debian's sparc build gets a bus error, as reported by Christoph Berg; perhaps it's assuming 8-byte alignment of the pointer? The lack of previous field reports is probably because you need all of these conditions to trigger a crash: an alignment-picky platform (not Intel), a transaction large enough to spill to disk, an update within that xact that changes a primary-key field and has an odd-length old tuple, and of course logical decoding tracing the transaction. Avoid the alignment assumption by using memcpy instead of fetching t_len directly, and add a test case that exposes the crash on picky platforms. Back-patch to 9.4 where the bug was introduced. Discussion: <20160413094117.GC21485@msg.credativ.de>		10 years ago
..
expected	Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms.	10 years ago
specs	…
sql	Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms.	10 years ago
.gitignore	…
Makefile	Generic Messages for Logical Decoding	10 years ago
logical.conf	…
test_decoding.c	Generic Messages for Logical Decoding	10 years ago