Our configure script goes to considerable lengths to try to identify what printf width modifier to use for int64 values. In particular see PGAC_FUNC_SNPRINTF_LONG_LONG_INT_MODIFIER, which claims
# MinGW uses '%I64d', though gcc throws a warning with -Wall, # while '%lld' doesn't generate a warning, but doesn't work. However, if we decide that we ought to use our own snprintf replacement, we throw that info away and set INT64_FORMAT to "%lld" which we know is what that code uses. This was all right when that code was first written, when we had only a very small number of uses of INT64_FORMAT and they all were in snprintf() calls. It's been a long time since that was true: pgbench, in particular, has been passing INT64_FORMAT to the native printf with increasing enthusiasm. In reality, we do not anymore work with situations where our snprintf has a different idea about this format modifier than libc does. What's more, as far as I can find, we do not have any buildfarm members that set INT64_MODIFIER to anything other than "l" or "ll", which no doubt explains why we've not noticed a problem. The comment quoted above doesn't seem to apply to any current buildfarm members. I think we should abandon the pretense that we can work with libc printfs that accept anything but "l"/"ll", and rip out the excess complexity in configure, just setting INT64_MODIFIER to "l" or "ll" depending on whether "int64" is "long" or "long long". Comments? regards, tom lane