On Sat, Oct 5, 2013 at 1:34 AM, David Rowley <dgrowle...@gmail.com> wrote:
> On Sat, Oct 5, 2013 at 1:19 AM, Andres Freund <and...@2ndquadrant.com>wrote:
>
>> On 2013-10-05 01:05:37 +1300, David Rowley wrote:
>> > In HEAD of 9.4 I'm getting the following:
>> >
>> > D:\9.4\bin>postgres.exe -D d:\9.4\data
>> > LOG: database system was shut down at 2013-10-05 00:43:33 NZDT
>> > LOG: database system is ready to accept connections
>> > LOG: autovacuum launcher started
>> > PANIC: space reserved for WAL record does not match what was written:
>> > CurrPos = 18446744071562067968 EndPos = 2147483648
>>
>> Could it be that MAXALIGN/TYPEALIGN doesn't really work for values
>> bigger than 32bit?
>>
>> #define MAXALIGN(LEN) TYPEALIGN(MAXIMUM_ALIGNOF, (LEN))
>> #define TYPEALIGN(ALIGNVAL,LEN) \
>> (((intptr_t) (LEN) + ((ALIGNVAL) - 1)) & ~((intptr_t) ((ALIGNVAL)
>> - 1)))
>>
>>
> It looks that way.
>
> As a quick test I put some printf's around where the MAXALIGN is used:
>
> /* Align the end position, so that the next record starts aligned */
> printf("CurrPos == %llu (before MAXALIGN)\n", CurrPos);
> CurrPos = MAXALIGN(CurrPos);
> printf("CurrPos == %llu (after MAXALIGN)\n", CurrPos);
>
> I got the following just before the PANIC.
>
> CurrPos == 2147483711 (before MAXALIGN)
> CurrPos == 18446744071562068032 (after MAXALIGN)
>
So I guess this would also break the 32bit linux builds too.
I've attached a proposed patch which seems to fix the problem.
Regards
David
>
> Regards
>
> David
>
>
maxalign64.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
