Re: Replication identifiers, take 4

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