mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-30 00:27:18 +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.sql | ||
ddl.sql | ||
decoding_in_xact.sql | ||
decoding_into_rel.sql | ||
messages.sql | ||
permissions.sql | ||
prepared.sql | ||
replorigin.sql | ||
rewrite.sql | ||
time.sql | ||
toast.sql | ||
xact.sql |