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

From Andres Freund
Subject Re: space reserved for WAL record does not match what was written: panic on windows
Date
Msg-id 20131008222459.GD3718183@alap2.anarazel.de
Whole thread Raw
In response to Re: space reserved for WAL record does not match what was written: panic on windows  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: space reserved for WAL record does not match what was written: panic on windows
List pgsql-hackers
On 2013-10-08 12:26:17 -0400, Robert Haas wrote:
> On Mon, Oct 7, 2013 at 4:47 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > So I guess it's either a separate macro, or we rewrite that piece of
> > code to work slightly differently and work directly on the lenght or
> > such.
> >
> > Maybe we should add a StaticAssert ensuring the TYPEALIGN macro only
> > gets passed 32bit types?
> 
> I think having two macros that behave identically on all platforms
> anyone cares about[1] but which can cause difficult-to-find
> corner-case-bugs on other platforms is just a recipe for disaster.  I
> pledge to screw that up at least once.

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.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: drop-index-concurrently-1 on master fails at serializable
Next
From: Ian Lawrence Barwick
Date:
Subject: Re: Patch: FORCE_NULL option for copy COPY in CSV mode