Noah Misch <n...@leadboat.com> writes: > I hacked psql to call PQtrace() and ran "psql -Xc 'select true'" in the > defective configuration and in a working x64 GNU/Linux configuration. I've > attached both PQtrace() products.
Thanks. It looks to me like the xlc build simply forgets to send some of the T-message fields: the message length observed by the frontend is too short, and the reported field values starting with "1140850688" correspond to the actual contents of the subsequent D message, rather than what should be there. Studying the values that are returned, a plausible conclusion is that in the sequence pq_writestring(buf, NameStr(att->attname)); pq_writeint32(buf, resorigtbl); pq_writeint16(buf, resorigcol); pq_writeint32(buf, atttypid); pq_writeint16(buf, att->attlen); pq_writeint32(buf, atttypmod); pq_writeint16(buf, format); the pq_writeint32 calls are somehow becoming no-ops. That would explain the message being exactly 12 bytes too short, and the 6 bytes that are there match what the pq_writeint16 calls should send. Looking at the pq_writeintN function definitions, I'm annoyed by the fact that Andres seems to have decided whether to write sizeof(ni) or sizeof(i) with the aid of a ouija board. That should be consistent. I'd go with sizeof(ni) myself, since that's the object actually being memcpy'd. It seems unlikely that that could explain this bug, but maybe somehow sizeof() misbehaves for a parameter that's been inlined away? Anyway, I will go make the sizeof() usages consistent, just to satisfy my own uncontrollable neatnik-ism. Assuming that hornet stays red, which is probable, we should disable "restrict" for that compiler. regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers