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