pgsql: Replace use of strerror() with %s by %m in pg_waldump

2019-12-23 Thread Michael Paquier
Replace use of strerror() with %s by %m in pg_waldump Since d6c55de1, src/port/snprintf.c is able to use %m instead of strerror(). A couple of utilities in src/bin/ have already done the switch, and do it now for pg_waldump as this reduces the workload for translators. Note that more could be do

pgsql: Rotate instead of shifting hash join batch number.

2019-12-23 Thread Thomas Munro
Rotate instead of shifting hash join batch number. Our algorithm for choosing batch numbers turned out not to work effectively for multi-billion key inner relations. We would use more hash bits than we have, and effectively concentrate all tuples into a smaller number of batches than we intended.

pgsql: Rotate instead of shifting hash join batch number.

2019-12-23 Thread Thomas Munro
Rotate instead of shifting hash join batch number. Our algorithm for choosing batch numbers turned out not to work effectively for multi-billion key inner relations. We would use more hash bits than we have, and effectively concentrate all tuples into a smaller number of batches than we intended.

pgsql: Rotate instead of shifting hash join batch number.

2019-12-23 Thread Thomas Munro
Rotate instead of shifting hash join batch number. Our algorithm for choosing batch numbers turned out not to work effectively for multi-billion key inner relations. We would use more hash bits than we have, and effectively concentrate all tuples into a smaller number of batches than we intended.

pgsql: Rotate instead of shifting hash join batch number.

2019-12-23 Thread Thomas Munro
Rotate instead of shifting hash join batch number. Our algorithm for choosing batch numbers turned out not to work effectively for multi-billion key inner relations. We would use more hash bits than we have, and effectively concentrate all tuples into a smaller number of batches than we intended.

pgsql: Rotate instead of shifting hash join batch number.

2019-12-23 Thread Thomas Munro
Rotate instead of shifting hash join batch number. Our algorithm for choosing batch numbers turned out not to work effectively for multi-billion key inner relations. We would use more hash bits than we have, and effectively concentrate all tuples into a smaller number of batches than we intended.

pgsql: Rotate instead of shifting hash join batch number.

2019-12-23 Thread Thomas Munro
Rotate instead of shifting hash join batch number. Our algorithm for choosing batch numbers turned out not to work effectively for multi-billion key inner relations. We would use more hash bits than we have, and effectively concentrate all tuples into a smaller number of batches than we intended.

pgsql: Rotate instead of shifting hash join batch number.

2019-12-23 Thread Thomas Munro
Rotate instead of shifting hash join batch number. Our algorithm for choosing batch numbers turned out not to work effectively for multi-billion key inner relations. We would use more hash bits than we have, and effectively concentrate all tuples into a smaller number of batches than we intended.

pgsql: Disallow null category in crosstab_hash

2019-12-23 Thread Joe Conway
Disallow null category in crosstab_hash While building a hash map of categories in load_categories_hash, resulting category names have not thus far been checked to ensure they are not null. Prior to pg12 null category names worked to the extent that they did not crash on some platforms. This is be

pgsql: Disallow null category in crosstab_hash

2019-12-23 Thread Joe Conway
Disallow null category in crosstab_hash While building a hash map of categories in load_categories_hash, resulting category names have not thus far been checked to ensure they are not null. Prior to pg12 null category names worked to the extent that they did not crash on some platforms. This is be

pgsql: Disallow null category in crosstab_hash

2019-12-23 Thread Joe Conway
Disallow null category in crosstab_hash While building a hash map of categories in load_categories_hash, resulting category names have not thus far been checked to ensure they are not null. Prior to pg12 null category names worked to the extent that they did not crash on some platforms. This is be

pgsql: Disallow null category in crosstab_hash

2019-12-23 Thread Joe Conway
Disallow null category in crosstab_hash While building a hash map of categories in load_categories_hash, resulting category names have not thus far been checked to ensure they are not null. Prior to pg12 null category names worked to the extent that they did not crash on some platforms. This is be

pgsql: Disallow null category in crosstab_hash

2019-12-23 Thread Joe Conway
Disallow null category in crosstab_hash While building a hash map of categories in load_categories_hash, resulting category names have not thus far been checked to ensure they are not null. Prior to pg12 null category names worked to the extent that they did not crash on some platforms. This is be

pgsql: Disallow null category in crosstab_hash

2019-12-23 Thread Joe Conway
Disallow null category in crosstab_hash While building a hash map of categories in load_categories_hash, resulting category names have not thus far been checked to ensure they are not null. Prior to pg12 null category names worked to the extent that they did not crash on some platforms. This is be

pgsql: Disallow null category in crosstab_hash

2019-12-23 Thread Joe Conway
Disallow null category in crosstab_hash While building a hash map of categories in load_categories_hash, resulting category names have not thus far been checked to ensure they are not null. Prior to pg12 null category names worked to the extent that they did not crash on some platforms. This is be

pgsql: Disallow partition key expressions that return pseudo-types.

2019-12-23 Thread Tom Lane
Disallow partition key expressions that return pseudo-types. This wasn't checked originally, but it should have been, because in general pseudo-types can't be stored to and retrieved from disk. Notably, partition bound values of type "record" would not be interpretable by another session. In v12

pgsql: Disallow partition key expressions that return pseudo-types.

2019-12-23 Thread Tom Lane
Disallow partition key expressions that return pseudo-types. This wasn't checked originally, but it should have been, because in general pseudo-types can't be stored to and retrieved from disk. Notably, partition bound values of type "record" would not be interpretable by another session. In v12

pgsql: Disallow partition key expressions that return pseudo-types.

2019-12-23 Thread Tom Lane
Disallow partition key expressions that return pseudo-types. This wasn't checked originally, but it should have been, because in general pseudo-types can't be stored to and retrieved from disk. Notably, partition bound values of type "record" would not be interpretable by another session. In v12

pgsql: Disallow partition key expressions that return pseudo-types.

2019-12-23 Thread Tom Lane
Disallow partition key expressions that return pseudo-types. This wasn't checked originally, but it should have been, because in general pseudo-types can't be stored to and retrieved from disk. Notably, partition bound values of type "record" would not be interpretable by another session. In v12

pgsql: Prevent a rowtype from being included in itself via a range.

2019-12-23 Thread Tom Lane
Prevent a rowtype from being included in itself via a range. We probably should have thought of this case when ranges were added, but we didn't. (It's not the fault of commit eb51af71f, because ranges didn't exist then.) It's an old bug, so back-patch to all supported branches. Discussion: http

pgsql: Prevent a rowtype from being included in itself via a range.

2019-12-23 Thread Tom Lane
Prevent a rowtype from being included in itself via a range. We probably should have thought of this case when ranges were added, but we didn't. (It's not the fault of commit eb51af71f, because ranges didn't exist then.) It's an old bug, so back-patch to all supported branches. Discussion: http

pgsql: Prevent a rowtype from being included in itself via a range.

2019-12-23 Thread Tom Lane
Prevent a rowtype from being included in itself via a range. We probably should have thought of this case when ranges were added, but we didn't. (It's not the fault of commit eb51af71f, because ranges didn't exist then.) It's an old bug, so back-patch to all supported branches. Discussion: http

pgsql: Prevent a rowtype from being included in itself via a range.

2019-12-23 Thread Tom Lane
Prevent a rowtype from being included in itself via a range. We probably should have thought of this case when ranges were added, but we didn't. (It's not the fault of commit eb51af71f, because ranges didn't exist then.) It's an old bug, so back-patch to all supported branches. Discussion: http

pgsql: Prevent a rowtype from being included in itself via a range.

2019-12-23 Thread Tom Lane
Prevent a rowtype from being included in itself via a range. We probably should have thought of this case when ranges were added, but we didn't. (It's not the fault of commit eb51af71f, because ranges didn't exist then.) It's an old bug, so back-patch to all supported branches. Discussion: http

pgsql: Prevent a rowtype from being included in itself via a range.

2019-12-23 Thread Tom Lane
Prevent a rowtype from being included in itself via a range. We probably should have thought of this case when ranges were added, but we didn't. (It's not the fault of commit eb51af71f, because ranges didn't exist then.) It's an old bug, so back-patch to all supported branches. Discussion: http

pgsql: Prevent a rowtype from being included in itself via a range.

2019-12-23 Thread Tom Lane
Prevent a rowtype from being included in itself via a range. We probably should have thought of this case when ranges were added, but we didn't. (It's not the fault of commit eb51af71f, because ranges didn't exist then.) It's an old bug, so back-patch to all supported branches. Discussion: http

pgsql: GetPublicationByName: Don't repeat ourselves

2019-12-23 Thread Alvaro Herrera
GetPublicationByName: Don't repeat ourselves Use get_publication_oid() instead of reimplementing it. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0fd8cfb20d2d41d4c2df021a5f355965fd8d21bc Modi