Re: Replication identifiers, take 4

On 17 April 2015 at 19:18, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> To be honest, I'm not entirely sure what we're arguing over.

When arguing over something you consider small, it is customary to allow
the author precedence. We can't do things our own way all the time.

I didn't much like pg_rewind, but it doesn't hurt and you like it, so I
didn't object. We've all got better things to do.

> 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.

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.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services