Re: space reserved for WAL record does not match what was written: panic on windows

On Thu, Oct 17, 2013 at 12:33 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> But if we're bent on minimizing the use of 64-bit arithmetic on 32-bit
>> systems, then presumably I should instead go back and retrofit that
>> patch to use Size rather than uint64 to represent the size of a
>> segment. But then I have two concerns:
>
> I'm not bent on _minimizing_ use of 64-bit arithmetic on 32-bit systems, but I
> disfavor an addition of such usage rippling through various hot paths of the
> system indiscriminately. Making a design choice to use *ALIGN64 in a
> particular module doesn't bother me that way.

OK. Well that'd probably be simpler from my point of view but I'm not
100% sure. If we're going to allow that, then I think we need 64-bit
versions of all of the alignment macros. Anyone think that's a bad
idea?

>> 1. Is there any guarantee that sizeof(intptr_t) >= sizeof(size_t)?
>> (Note that Size is just a typedef for size_t, in c.h)
>
> C99 doesn't require it, but I have never heard of a platform where it is
> false. sizeof(intptr_t) > sizeof(size_t) systems have existed.

That's good, I think. Because if it weren't true then we'd
potentially need three versions of this macro: one for intptr_t,
another for size_t, and a third for uint64.

>> 2. If intptr_t is a signed type, as it appears to be, and size_t is an
>> unsigned type, as I believe it to be, then is it safe to use the
>> macros written for the signed type with a value of the unsigned type?
>> Off-hand I can't see a problem there, but I'm not certain I'm not
>> missing something.
>
> Yes; we do that all the time, e.g. the MAXALIGN call in AllocSetAlloc().
> Looping back to my question above, I think it doesn't matter (on a two's
> complement system) whether the macro uses a signed type or an unsigned type.
> It changes the type of the result; that's all. Nonetheless, we should be
> consistent about signedness between the regular and 64-bit macro variants.

So, are you proposing using uintptr_t there instead of intptr_t? Or what?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company