mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-30 01:37:19 +02:00
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> |
||
---|---|---|
.. | ||
binary.out | ||
concurrent_ddl_dml.out | ||
ddl.out | ||
decoding_in_xact.out | ||
decoding_into_rel.out | ||
delayed_startup.out | ||
messages.out | ||
mxact.out | ||
ondisk_startup.out | ||
permissions.out | ||
prepared.out | ||
replorigin.out | ||
rewrite.out | ||
time.out | ||
toast.out | ||
xact.out |