Re: pgsql: Improve performance of SendRowDescriptionMessage.

Noah Misch <noah(at)leadboat(dot)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