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+TgmoadkNjMVPKwiwvNx3hF8sFe9mOXq9xKZirODz8fPdmYiw@mail.gmail.com
Whole thread Raw
In response to Re: space reserved for WAL record does not match what was written: panic on windows  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: space reserved for WAL record does not match what was written: panic on windows  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Tue, Oct 8, 2013 at 6:24 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> Do you have a better alternative? Making the computation unconditionally
> 64bit will have a runtime overhead and adding a StaticAssert in the
> existing macro doesn't work because we use it in array sizes where gcc
> balks.
> We could try using inline functions, but that's not going to be pretty
> either.
>
> I don't really see that many further usecases that will align 64bit
> values on 32bit platforms, so I think we're ok for now.

I'd be inclined to make the computation unconditionally 64-bit.  I
doubt the speed penalty is enough to worry about, and I think we're
going to have more and more cases where optimizing for 32-bit
platforms is just not the right decision.

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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Auto-tuning work_mem and maintenance_work_mem
Next
From: Andrew Dunstan
Date:
Subject: Re: Patch: FORCE_NULL option for copy COPY in CSV mode