Re: space reserved for WAL record does not match what was written: panic on windows - Mailing list pgsql-hackers

From Robert Haas
Subject Re: space reserved for WAL record does not match what was written: panic on windows
Date
Msg-id CA+TgmoY_LMkKrusCO9pGGzCKtk5uv2zY=uCaKnwfOrNFeTZUug@mail.gmail.com
Whole thread Raw
In response to Re: space reserved for WAL record does not match what was written: panic on windows  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Thu, Oct 17, 2013 at 12:33 PM, Noah Misch <noah@leadboat.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] pg_sleep(interval)
Next
From: Andres Freund
Date:
Subject: Re: space reserved for WAL record does not match what was written: panic on windows