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 20131010132330.GA3924560@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  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On 2013-10-10 08:59:47 -0400, Robert Haas wrote:
> 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.

MAXALIGN is used in several of PG's hottest functions in many
scenarios. att_align_nominal is used in slot_deform_tuple,
heap_deform_tuple, nocachegetattr, etc. So I don't think that's viable
yet. At least not with much more benefit than this...

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Patch: FORCE_NULL option for copy COPY in CSV mode
Next
From: Merlin Moncure
Date:
Subject: Re: PSQL return coder