mirror of
https://github.com/postgres/postgres.git
synced 2026-03-06 15:25:15 -05:00
e7a456174b
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 | ||
| mxact.out | ||
| ondisk_startup.out | ||
| permissions.out | ||
| prepared.out | ||
| replorigin.out | ||
| rewrite.out | ||
| time.out | ||
| toast.out | ||
| xact.out | ||