On 17/04/15 22:36, Simon Riggs wrote:
>
> I said that IMO the difference in WAL size is so small that we
> should just use 4-byte OIDs for the replication identifiers, instead
> of trying to make do with 2 bytes. Not because I find it too likely
> that you'll run out of IDs (although it could happen), but more to
> make replication IDs more like all other system objects we have.
> Andreas did some pgbench benchmarking to show that the difference in
> WAL size is about 10%. The WAL records generated by pgbench happen
> to have just the right sizes so that the 2-3 extra bytes bump them
> over to the next alignment boundary. That's why there is such a big
> difference - on average it'll be less. I think that's acceptable,
> Andreas seems to think otherwise. But if the WAL size really is so
> precious, we could remove the two padding bytes from XLogRecord,
> instead of dedicating them for the replication ids. That would be an
> even better use for them.
>
>
> The argument to move to 4 bytes is a poor one. If it was reasonable in
> terms of code or cosmetic value then all values used in the backend
> would be 4 bytes. We wouldn't have any 2 byte values anywhere. But we
> don't do that.
>
> The change does nothing useful, since I doubt anyone will ever need
> >32768 nodes in their cluster.
>
And if they did there would be other much bigger problems than
replication identifier being 16bit (it's actually >65534 as it's
unsigned btw).
Considering the importance and widespread use of replication I think we
should really make sure the related features have small overhead.
> Increasing WAL size for any non-zero amount is needlessly wasteful for a
> change with only cosmetic value. But for a change that has significant
> value for database resilience, it is a sensible use of bytes.
>
> +1 to Andres' very reasonable suggestion. Lets commit this and go home.
>
+1
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services