On Tue, Mar 16, 2021 at 12:51 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > Yeah, that looks related: > > regression=# select attname, attlen, attnum, attalign from pg_attribute where > attrelid = 2619 and attname like 'stavalue%'; > attname | attlen | attnum | attalign > ------------+--------+--------+---------- > stavalues1 | -1 | 27 | d > stavalues2 | -1 | 28 | d > stavalues3 | -1 | 29 | d > stavalues4 | -1 | 30 | d > stavalues5 | -1 | 31 | d > (5 rows) > > It shows them all has having attalign = 'd', but for some array types the > alignment will be 'i', not 'd'. So it's lying a bit about the contents. But > I'm now confused why this caused problems on the two hosts where integer and > double have the same alignment? It seems like that would be the one place > where the bug would not happen, not the one place where it does.
Wait, so the value in the attalign column isn't the alignment we're actually using? I can understand how we might generate tuples like that, if we pass the actual type to construct_array(), but shouldn't we then get garbage when we deform the tuple? I mean, heap_deform_tuple() is going to get the alignment from the tuple descriptor, which is a table property. It doesn't (and can't) know what type of value is stored inside any of these fields for real, right? In other words, isn't this actually corruption, caused by a bug in our code, and how have we not noticed it before now? -- Robert Haas EDB: http://www.enterprisedb.com
