> On Mar 13, 2021, at 6:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: >> I think it would be good to use a non-zero value here. We're doing a >> lot of poking into raw bytes here, and if something goes wrong, a zero >> value is more likely to look like something normal than whatever else. >> I suggest picking a value where all 8 bytes are the same, but not >> zero, and ideally chosen so that they don't look much like any of the >> surrounding bytes. > > Actually, it seems like we can let pack/unpack deal with byte-swapping > within 32-bit words; what we lose by not using 'q' format is just the > ability to correctly swap the two 32-bit words. Hence, any value in > which upper and lower halves are the same should work, say > 0x1234567812345678. > > regards, tom lane
The heap tuple in question looks as follows, with ???????? in the spot we're debating: Tuple Layout (values in hex): t_xmin: 223 t_xmax: 0 t_field3: 0 bi_hi: 0 bi_lo: 0 ip_posid: 1 t_infomask2: 3 t_infomask: b06 t_hoff: 18 t_bits: 0 a_1: ???????? a_2: ???????? b_header: 11 # little-endian, will be 88 on big endian b_body1: 61 b_body2: 62 b_body3: 63 b_body4: 64 b_body5: 65 b_body6: 66 b_body7: 67 c_va_header: 1 c_va_vartag: 12 c_va_rawsize: 2714 c_va_extsize: 2710 valueid and toastrelid are not shown, as they won't be stable. Relying on t_xmin to be stable makes the test brittle, but fortunately that is separated from a_1 and a_2 far enough that we should not need to worry about it. We want to use values that don't look like any of the others. The complete set of nibbles in the values above is [012345678B], leaving the set [9ACDEF] unused. The attached patch uses the value DEADF9F9 as it seems a little easier to remember than other permutations of those nibbles.
v6-0001-pg_amcheck-continuing-to-fix-portability-problems.patch
Description: Binary data
— Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
