From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: XLog changes for 9.3 |
Date: | 2012-06-07 14:42:49 |
Message-ID: | 8644.1339080169@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> When I worked on the XLogInsert scaling patch, it became apparent that
> some changes to the WAL format would make it a lot easier. So for 9.3,
> I'd like to do some refactoring:
> 1. Use a 64-bit integer instead of the two-variable log/seg
> representation, for identifying a WAL segment. This has no user-visible
> effect, but makes the code a bit simpler.
> 2. Don't waste the last WAL segment in each logical 4GB file. Currently,
> we skip the WAL segment ending with "FF". The comments claim that
> wasting the last segment "ensures that we don't have problems
> representing last-byte-position-plus-1", but in my experience, it just
> makes things more complicated.
I think that's actually an indivisible part of point #1. The issue in
the 32+32 representation is that you'd overflow the low-order half when
trying to represent last-byte-of-file-plus-1, and have to do something
with propagating that to the high half. In a 64-bit continuous
addressing scheme the problem goes away, and it would just get more
complicated not less to preserve the "hole".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-06-07 15:04:23 | Re: "page is not marked all-visible" warning in regression tests |
Previous Message | Robert Haas | 2012-06-07 14:27:32 | Re: "page is not marked all-visible" warning in regression tests |