Fix partition ID byte order for s390x

[HarryLeeIBM]

On s390x, the partition ID has reversed byte order compared to those on little-endian machines. The fix is to reverse the byte order so that partition IDs keep the same on both little-endian and big-endian machines.

Changelog category (leave one):

• Not for changelog

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Fixed the byte order of partition IDs on s390x so that partition IDs keep the same on both little-endian and big-endian machines. This change does not affect other platforms.

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

Information about CI checks: https://clickhouse.com/docs/en/development/continuous-integration/

[tavplubix]

if constexpr (std::endian::native == std::endian::big) would be nicer

[HarryLeeIBM]

if constexpr (std::endian::native == std::endian::big) only works when it is in a template function. Since getID() is not a template function, using this way would cause compiling error.

[tavplubix]

Also let's change the changelog category to "Backward Incompatible Change" and make the changelog entry more detailed

[tavplubix]

And do we have the same issue with other usages of writeHexByteLowercase and writeHexByteUppercase? For example, here:

ClickHouse/src/Parsers/Access/ParserCreateUserQuery.cpp

Lines 192 to 201 in 9920a52

	String salt;
	salt.resize(sizeof(key) * 2);
	char * buf_pos = salt.data();
	for (uint8_t k : key)
	{
	writeHexByteUppercase(k, buf_pos);
	buf_pos += 2;
	}
	value.append(salt);
	auth_data.setSalt(salt);

[HarryLeeIBM]

And do we have the same issue with other usages of writeHexByteLowercase and writeHexByteUppercase? For example, here:

ClickHouse/src/Parsers/Access/ParserCreateUserQuery.cpp

Lines 192 to 201 in 9920a52

	String salt;
	salt.resize(sizeof(key) * 2);
	char * buf_pos = salt.data();
	for (uint8_t k : key)
	{
	writeHexByteUppercase(k, buf_pos);
	buf_pos += 2;
	}
	value.append(salt);
	auth_data.setSalt(salt);

This issue is unique because getID() uses SipHash128 to generate 128 bit wide integers for the partition ID. Even though the generated 128 bit integers are the same for both little-endian and big-endian machines, directly using the data of 128 bit integers would cause byte order issue in s390x.

[HarryLeeIBM]

Also let's change the changelog category to "Backward Incompatible Change" and make the changelog entry more detailed

Done.

[tavplubix]

Integration tests (tsan) [5/6] - #47839
Stateless tests (debug, s3 storage) [6/6] - #47866

[alexey-milovidov]

This is not a backward incompatible change.

[tavplubix]

This is not a backward incompatible change.

@alexey-milovidov, why? It changes partition ids on s390x platform. Of course, it does not affect other platforms, but it is backward incompatible for s390x.

[tavplubix]

This is not a backward incompatible change.

@alexey-milovidov, why? It changes partition ids on s390x platform. Of course, it does not affect other platforms, but it is backward incompatible for s390x.

[alexey-milovidov]

s390x is not supported for ClickHouse.