Re: space reserved for WAL record does not match what was written: panic on windows
От | Andres Freund |
---|---|
Тема | Re: space reserved for WAL record does not match what was written: panic on windows |
Дата | |
Msg-id | 20131010132330.GA3924560@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: space reserved for WAL record does not match what was written: panic on windows (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: space reserved for WAL record does not match what was written:
panic on windows
|
Список | 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 по дате отправления: