pgsql: Hash support for row types
Hash support for row types Add hash functions for the record type as well as a hash operator family and operator class for the record type. This enables all the hash functionality for the record type such as hash-based plans for UNION/INTERSECT/EXCEPT DISTINCT, recursive queries using UNION DISTINCT, hash joins, and hash partitioning. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/38eccd35-4e2d-6767-1b3c-dada1eac3124%402ndquadrant.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/01e658fa74cb7e3292448f6663b549135958003b Modified Files -- doc/src/sgml/queries.sgml | 9 -- src/backend/utils/adt/rowtypes.c| 249 src/backend/utils/cache/lsyscache.c | 7 +- src/backend/utils/cache/typcache.c | 78 +++--- src/include/catalog/catversion.h| 2 +- src/include/catalog/pg_amop.dat | 5 + src/include/catalog/pg_amproc.dat | 4 + src/include/catalog/pg_opclass.dat | 2 + src/include/catalog/pg_operator.dat | 2 +- src/include/catalog/pg_opfamily.dat | 2 + src/include/catalog/pg_proc.dat | 7 + src/test/regress/expected/hash_func.out | 21 +++ src/test/regress/expected/join.out | 1 + src/test/regress/expected/union.out | 83 ++- src/test/regress/expected/with.out | 33 - src/test/regress/sql/hash_func.sql | 17 +++ src/test/regress/sql/join.sql | 1 + src/test/regress/sql/union.sql | 12 +- src/test/regress/sql/with.sql | 2 +- 19 files changed, 462 insertions(+), 75 deletions(-)
pgsql: Rename object in test to avoid conflict
Rename object in test to avoid conflict In 01e658fa74cb7e3292448f6663b549135958003b, the hash_func test creates a type t1, but apparently a test running in parallel might also use that name, depending on timing. Rename the type to avoid the issue. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/afaccbba787d5f1470c44ddd61c9ddaaad19e27e Modified Files -- src/test/regress/expected/hash_func.out | 14 +++--- src/test/regress/sql/hash_func.sql | 14 +++--- 2 files changed, 14 insertions(+), 14 deletions(-)
pgsql: Further fixes for CREATE TABLE LIKE: cope with self-referential
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs. Commit 502898192 was too careless about the order of execution of the additional ALTER TABLE operations generated by expandTableLikeClause. It just stuck them all at the end, which seems okay for most purposes. But it falls down in the case where LIKE is importing a primary key or unique index and the outer CREATE TABLE includes a FOREIGN KEY constraint that needs to depend on that index. Weird as that is, it used to work, so we ought to keep it working. To fix, make parse_utilcmd.c insert LIKE clauses between index-creation and FK-creation commands in the transformed list of commands, and change utility.c so that the commands generated by expandTableLikeClause are executed immediately not at the end. One could imagine scenarios where this wouldn't work either; but currently expandTableLikeClause only makes column default expressions, CHECK constraints, and indexes, and this ordering seems fine for those. Per bug #16730 from Sofoklis Papasofokli. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/159b6775fad9b040fb181e5660a8149e57aa0609 Modified Files -- src/backend/parser/parse_utilcmd.c | 27 +++- src/backend/tcop/utility.c | 28 - src/test/regress/expected/create_table_like.out | 16 ++ src/test/regress/sql/create_table_like.sql | 5 + 4 files changed, 56 insertions(+), 20 deletions(-)
pgsql: Further fixes for CREATE TABLE LIKE: cope with self-referential
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs. Commit 502898192 was too careless about the order of execution of the additional ALTER TABLE operations generated by expandTableLikeClause. It just stuck them all at the end, which seems okay for most purposes. But it falls down in the case where LIKE is importing a primary key or unique index and the outer CREATE TABLE includes a FOREIGN KEY constraint that needs to depend on that index. Weird as that is, it used to work, so we ought to keep it working. To fix, make parse_utilcmd.c insert LIKE clauses between index-creation and FK-creation commands in the transformed list of commands, and change utility.c so that the commands generated by expandTableLikeClause are executed immediately not at the end. One could imagine scenarios where this wouldn't work either; but currently expandTableLikeClause only makes column default expressions, CHECK constraints, and indexes, and this ordering seems fine for those. Per bug #16730 from Sofoklis Papasofokli. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c690ebbefa3394b67ceb1ba913590d873ad40355 Modified Files -- src/backend/parser/parse_utilcmd.c | 27 +++- src/backend/tcop/utility.c | 28 - src/test/regress/expected/create_table_like.out | 16 ++ src/test/regress/sql/create_table_like.sql | 5 + 4 files changed, 56 insertions(+), 20 deletions(-)
pgsql: Further fixes for CREATE TABLE LIKE: cope with self-referential
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs. Commit 502898192 was too careless about the order of execution of the additional ALTER TABLE operations generated by expandTableLikeClause. It just stuck them all at the end, which seems okay for most purposes. But it falls down in the case where LIKE is importing a primary key or unique index and the outer CREATE TABLE includes a FOREIGN KEY constraint that needs to depend on that index. Weird as that is, it used to work, so we ought to keep it working. To fix, make parse_utilcmd.c insert LIKE clauses between index-creation and FK-creation commands in the transformed list of commands, and change utility.c so that the commands generated by expandTableLikeClause are executed immediately not at the end. One could imagine scenarios where this wouldn't work either; but currently expandTableLikeClause only makes column default expressions, CHECK constraints, and indexes, and this ordering seems fine for those. Per bug #16730 from Sofoklis Papasofokli. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/97390fe8a6e96a153e59b0180f4303acaeb75b84 Modified Files -- src/backend/parser/parse_utilcmd.c | 27 +++- src/backend/tcop/utility.c | 28 - src/test/regress/expected/create_table_like.out | 16 ++ src/test/regress/sql/create_table_like.sql | 5 + 4 files changed, 56 insertions(+), 20 deletions(-)
pgsql: Further fixes for CREATE TABLE LIKE: cope with self-referential
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs. Commit 502898192 was too careless about the order of execution of the additional ALTER TABLE operations generated by expandTableLikeClause. It just stuck them all at the end, which seems okay for most purposes. But it falls down in the case where LIKE is importing a primary key or unique index and the outer CREATE TABLE includes a FOREIGN KEY constraint that needs to depend on that index. Weird as that is, it used to work, so we ought to keep it working. To fix, make parse_utilcmd.c insert LIKE clauses between index-creation and FK-creation commands in the transformed list of commands, and change utility.c so that the commands generated by expandTableLikeClause are executed immediately not at the end. One could imagine scenarios where this wouldn't work either; but currently expandTableLikeClause only makes column default expressions, CHECK constraints, and indexes, and this ordering seems fine for those. Per bug #16730 from Sofoklis Papasofokli. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/87ab464219259abdc06b0492f0d42bc6734ae490 Modified Files -- src/backend/parser/parse_utilcmd.c | 27 +++- src/backend/tcop/utility.c | 28 - src/test/regress/expected/create_table_like.out | 16 ++ src/test/regress/sql/create_table_like.sql | 5 + 4 files changed, 56 insertions(+), 20 deletions(-)
pgsql: Further fixes for CREATE TABLE LIKE: cope with self-referential
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs. Commit 502898192 was too careless about the order of execution of the additional ALTER TABLE operations generated by expandTableLikeClause. It just stuck them all at the end, which seems okay for most purposes. But it falls down in the case where LIKE is importing a primary key or unique index and the outer CREATE TABLE includes a FOREIGN KEY constraint that needs to depend on that index. Weird as that is, it used to work, so we ought to keep it working. To fix, make parse_utilcmd.c insert LIKE clauses between index-creation and FK-creation commands in the transformed list of commands, and change utility.c so that the commands generated by expandTableLikeClause are executed immediately not at the end. One could imagine scenarios where this wouldn't work either; but currently expandTableLikeClause only makes column default expressions, CHECK constraints, and indexes, and this ordering seems fine for those. Per bug #16730 from Sofoklis Papasofokli. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/513db7b7004c8d1fa15dea4747a32cbc8f9621ef Modified Files -- src/backend/parser/parse_utilcmd.c | 27 +++- src/backend/tcop/utility.c | 28 - src/test/regress/expected/create_table_like.out | 16 ++ src/test/regress/sql/create_table_like.sql | 5 + 4 files changed, 56 insertions(+), 20 deletions(-)
pgsql: Further fixes for CREATE TABLE LIKE: cope with self-referential
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs. Commit 502898192 was too careless about the order of execution of the additional ALTER TABLE operations generated by expandTableLikeClause. It just stuck them all at the end, which seems okay for most purposes. But it falls down in the case where LIKE is importing a primary key or unique index and the outer CREATE TABLE includes a FOREIGN KEY constraint that needs to depend on that index. Weird as that is, it used to work, so we ought to keep it working. To fix, make parse_utilcmd.c insert LIKE clauses between index-creation and FK-creation commands in the transformed list of commands, and change utility.c so that the commands generated by expandTableLikeClause are executed immediately not at the end. One could imagine scenarios where this wouldn't work either; but currently expandTableLikeClause only makes column default expressions, CHECK constraints, and indexes, and this ordering seems fine for those. Per bug #16730 from Sofoklis Papasofokli. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6631d5f261e9fdc2ccc2a81214a45865d6e59122 Modified Files -- src/backend/parser/parse_utilcmd.c | 27 +++- src/backend/tcop/utility.c | 28 - src/test/regress/expected/create_table_like.out | 16 ++ src/test/regress/sql/create_table_like.sql | 5 + 4 files changed, 56 insertions(+), 20 deletions(-)
pgsql: Further fixes for CREATE TABLE LIKE: cope with self-referential
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs. Commit 502898192 was too careless about the order of execution of the additional ALTER TABLE operations generated by expandTableLikeClause. It just stuck them all at the end, which seems okay for most purposes. But it falls down in the case where LIKE is importing a primary key or unique index and the outer CREATE TABLE includes a FOREIGN KEY constraint that needs to depend on that index. Weird as that is, it used to work, so we ought to keep it working. To fix, make parse_utilcmd.c insert LIKE clauses between index-creation and FK-creation commands in the transformed list of commands, and change utility.c so that the commands generated by expandTableLikeClause are executed immediately not at the end. One could imagine scenarios where this wouldn't work either; but currently expandTableLikeClause only makes column default expressions, CHECK constraints, and indexes, and this ordering seems fine for those. Per bug #16730 from Sofoklis Papasofokli. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/98f3f1d5c1bff02a25a0af7dcf3a4676dddf58e1 Modified Files -- src/backend/parser/parse_utilcmd.c | 27 +++- src/backend/tcop/utility.c | 28 - src/test/regress/expected/create_table_like.out | 16 ++ src/test/regress/sql/create_table_like.sql | 5 + 4 files changed, 56 insertions(+), 20 deletions(-)
pgsql: Adjust DSM and DSA slot usage constants (back-patch).
Adjust DSM and DSA slot usage constants (back-patch). 1. Previously, a DSA area would create up to four segments at each size before doubling the size. After this commit, it will create only two at each size, so it ramps up faster and therefore needs fewer slots. 2. Previously, the total limit on DSM slots allowed for 2 per connection. Switch to 5 per connection. This back-patches commit d061ea21 from release 13 into 10-12 based on a field complaint. Discussion: https://postgr.es/m/CAO03teA%2BjE1qt5iWDWzHqaufqBsF6EoOgZphnazps_tr_jDPZA%40mail.gmail.com Discussion: https://postgr.es/m/CA%2BhUKGL6H2BpGbiF7Lj6QiTjTGyTLW_vLR%3DSn2tEBeTcYXiMKw%40mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2ded1f1fbb6e8e2b7927cce93238775604069bc3 Modified Files -- src/backend/storage/ipc/dsm.c | 7 +-- src/backend/utils/mmgr/dsa.c | 2 +- 2 files changed, 2 insertions(+), 7 deletions(-)
pgsql: Adjust DSM and DSA slot usage constants (back-patch).
Adjust DSM and DSA slot usage constants (back-patch). 1. Previously, a DSA area would create up to four segments at each size before doubling the size. After this commit, it will create only two at each size, so it ramps up faster and therefore needs fewer slots. 2. Previously, the total limit on DSM slots allowed for 2 per connection. Switch to 5 per connection. This back-patches commit d061ea21 from release 13 into 10-12 based on a field complaint. Discussion: https://postgr.es/m/CAO03teA%2BjE1qt5iWDWzHqaufqBsF6EoOgZphnazps_tr_jDPZA%40mail.gmail.com Discussion: https://postgr.es/m/CA%2BhUKGL6H2BpGbiF7Lj6QiTjTGyTLW_vLR%3DSn2tEBeTcYXiMKw%40mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0455f78ddbb09b6ad3bb6b582b75fd3975a24541 Modified Files -- src/backend/storage/ipc/dsm.c | 7 +-- src/backend/utils/mmgr/dsa.c | 2 +- 2 files changed, 2 insertions(+), 7 deletions(-)
pgsql: Adjust DSM and DSA slot usage constants (back-patch).
Adjust DSM and DSA slot usage constants (back-patch). 1. Previously, a DSA area would create up to four segments at each size before doubling the size. After this commit, it will create only two at each size, so it ramps up faster and therefore needs fewer slots. 2. Previously, the total limit on DSM slots allowed for 2 per connection. Switch to 5 per connection. This back-patches commit d061ea21 from release 13 into 10-12 based on a field complaint. Discussion: https://postgr.es/m/CAO03teA%2BjE1qt5iWDWzHqaufqBsF6EoOgZphnazps_tr_jDPZA%40mail.gmail.com Discussion: https://postgr.es/m/CA%2BhUKGL6H2BpGbiF7Lj6QiTjTGyTLW_vLR%3DSn2tEBeTcYXiMKw%40mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f5332503ef0a65b90366c2a222e1b5aa64977a95 Modified Files -- src/backend/storage/ipc/dsm.c | 7 +-- src/backend/utils/mmgr/dsa.c | 2 +- 2 files changed, 2 insertions(+), 7 deletions(-)
pgsql: Remove undocumented IS [NOT] OF syntax.
Remove undocumented IS [NOT] OF syntax. This feature was added a long time ago, in 7c1e67bd5 and eb121ba2c, but never documented in any user-facing way. (Documentation added in 6126d3e70 was commented out almost immediately, in 8272fc3f7.) That's because, while this syntax is defined by SQL:99, our implementation is only vaguely related to the standard's semantics. The standard appears to intend a run-time not parse-time test, and it definitely intends that the test should understand subtype relationships. No one has stepped up to fix that in the intervening years, but people keep coming across the code and asking why it's not documented. Let's just get rid of it: if anyone ever wants to make it work per spec, they can easily recover whatever parts of this code are still of value from our git history. If there's anyone out there who's actually using this despite its undocumented status, they can switch to using pg_typeof() instead, eg. "pg_typeof(something) = 'mytype'::regtype". That gives essentially the same semantics as what our IS OF code did. (We didn't have that function last time this was discussed, or we would have ripped out IS OF then.) Discussion: https://postgr.es/m/cakfquwz2ptc-dskoitfjauqlyknreenzvwmeg12q-_69d+s...@mail.gmail.com Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/926fa801ac9eb54c5275472271ec63a059904698 Modified Files -- doc/src/sgml/func.sgml | 19 - src/backend/catalog/sql_features.txt | 2 +- src/backend/nodes/outfuncs.c | 4 --- src/backend/parser/gram.y| 16 --- src/backend/parser/parse_expr.c | 54 src/include/nodes/parsenodes.h | 1 - src/test/regress/expected/arrays.out | 16 +-- src/test/regress/expected/domain.out | 22 ++- src/test/regress/expected/with.out | 28 +-- src/test/regress/sql/arrays.sql | 4 +-- src/test/regress/sql/domain.sql | 5 ++-- src/test/regress/sql/with.sql| 6 ++-- 12 files changed, 38 insertions(+), 139 deletions(-)
pgsql: On macOS, use -isysroot in link steps as well as compile steps.
On macOS, use -isysroot in link steps as well as compile steps. We previously put the -isysroot switch only into CPPFLAGS, theorizing that it was only needed to find the right copies of include files. However, it seems that we also need to use it while linking programs, to find the right stub ".tbd" files for libraries. We got away without that up to now, but apparently that was mostly luck. It may also be that failures are only observed when the Xcode version is noticeably out of sync with the host macOS version; the case that's prompting action right now is that builds fail when using latest Xcode (12.2) on macOS Catalina, even though it's fine on Big Sur. Hence, add -isysroot to LDFLAGS as well. (It seems that the more common practice is to put it in CFLAGS, whence it'd be included at both compile and link steps. However, we can't mess with CFLAGS in the platform template file without confusing configure's logic for choosing default CFLAGS.) This should be back-patched, but first let's see if the buildfarm likes it on HEAD. Report and patch by James Hilliard (some cosmetic mods by me) Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/49407dc32a2931550e4ff1dea314b6a25afdfc35 Modified Files -- configure | 2 ++ configure.ac| 2 ++ src/template/darwin | 1 + 3 files changed, 5 insertions(+)
pgsql: On macOS, use -isysroot in link steps as well as compile steps.
On macOS, use -isysroot in link steps as well as compile steps. We previously put the -isysroot switch only into CPPFLAGS, theorizing that it was only needed to find the right copies of include files. However, it seems that we also need to use it while linking programs, to find the right stub ".tbd" files for libraries. We got away without that up to now, but apparently that was mostly luck. It may also be that failures are only observed when the Xcode version is noticeably out of sync with the host macOS version; the case that's prompting action right now is that builds fail when using latest Xcode (12.2) on macOS Catalina, even though it's fine on Big Sur. Hence, add -isysroot to LDFLAGS as well. (It seems that the more common practice is to put it in CFLAGS, whence it'd be included at both compile and link steps. However, we can't mess with CFLAGS in the platform template file without confusing configure's logic for choosing default CFLAGS.) Back-patch of 49407dc32 into all supported branches. Report and patch by James Hilliard (some cosmetic mods by me) Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2bb8c0f1d94dd4b2d23ae56b2f5ebec785d2df7b Modified Files -- configure | 2 ++ configure.in| 2 ++ src/template/darwin | 1 + 3 files changed, 5 insertions(+)
pgsql: On macOS, use -isysroot in link steps as well as compile steps.
On macOS, use -isysroot in link steps as well as compile steps. We previously put the -isysroot switch only into CPPFLAGS, theorizing that it was only needed to find the right copies of include files. However, it seems that we also need to use it while linking programs, to find the right stub ".tbd" files for libraries. We got away without that up to now, but apparently that was mostly luck. It may also be that failures are only observed when the Xcode version is noticeably out of sync with the host macOS version; the case that's prompting action right now is that builds fail when using latest Xcode (12.2) on macOS Catalina, even though it's fine on Big Sur. Hence, add -isysroot to LDFLAGS as well. (It seems that the more common practice is to put it in CFLAGS, whence it'd be included at both compile and link steps. However, we can't mess with CFLAGS in the platform template file without confusing configure's logic for choosing default CFLAGS.) Back-patch of 49407dc32 into all supported branches. Report and patch by James Hilliard (some cosmetic mods by me) Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e7abc634f51dfb653fc95bb13cbf2468c466 Modified Files -- configure | 2 ++ configure.in| 2 ++ src/template/darwin | 1 + 3 files changed, 5 insertions(+)
pgsql: On macOS, use -isysroot in link steps as well as compile steps.
On macOS, use -isysroot in link steps as well as compile steps. We previously put the -isysroot switch only into CPPFLAGS, theorizing that it was only needed to find the right copies of include files. However, it seems that we also need to use it while linking programs, to find the right stub ".tbd" files for libraries. We got away without that up to now, but apparently that was mostly luck. It may also be that failures are only observed when the Xcode version is noticeably out of sync with the host macOS version; the case that's prompting action right now is that builds fail when using latest Xcode (12.2) on macOS Catalina, even though it's fine on Big Sur. Hence, add -isysroot to LDFLAGS as well. (It seems that the more common practice is to put it in CFLAGS, whence it'd be included at both compile and link steps. However, we can't mess with CFLAGS in the platform template file without confusing configure's logic for choosing default CFLAGS.) Back-patch of 49407dc32 into all supported branches. Report and patch by James Hilliard (some cosmetic mods by me) Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d01e37845c2262a0b51a59c77ff8ad7b855824f8 Modified Files -- configure | 2 ++ configure.in| 2 ++ src/template/darwin | 1 + 3 files changed, 5 insertions(+)
pgsql: On macOS, use -isysroot in link steps as well as compile steps.
On macOS, use -isysroot in link steps as well as compile steps. We previously put the -isysroot switch only into CPPFLAGS, theorizing that it was only needed to find the right copies of include files. However, it seems that we also need to use it while linking programs, to find the right stub ".tbd" files for libraries. We got away without that up to now, but apparently that was mostly luck. It may also be that failures are only observed when the Xcode version is noticeably out of sync with the host macOS version; the case that's prompting action right now is that builds fail when using latest Xcode (12.2) on macOS Catalina, even though it's fine on Big Sur. Hence, add -isysroot to LDFLAGS as well. (It seems that the more common practice is to put it in CFLAGS, whence it'd be included at both compile and link steps. However, we can't mess with CFLAGS in the platform template file without confusing configure's logic for choosing default CFLAGS.) Back-patch of 49407dc32 into all supported branches. Report and patch by James Hilliard (some cosmetic mods by me) Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5b83604270a6ffc06e8e9406d19b9f2e845b74f9 Modified Files -- configure | 2 ++ configure.in| 2 ++ src/template/darwin | 1 + 3 files changed, 5 insertions(+)
pgsql: On macOS, use -isysroot in link steps as well as compile steps.
On macOS, use -isysroot in link steps as well as compile steps. We previously put the -isysroot switch only into CPPFLAGS, theorizing that it was only needed to find the right copies of include files. However, it seems that we also need to use it while linking programs, to find the right stub ".tbd" files for libraries. We got away without that up to now, but apparently that was mostly luck. It may also be that failures are only observed when the Xcode version is noticeably out of sync with the host macOS version; the case that's prompting action right now is that builds fail when using latest Xcode (12.2) on macOS Catalina, even though it's fine on Big Sur. Hence, add -isysroot to LDFLAGS as well. (It seems that the more common practice is to put it in CFLAGS, whence it'd be included at both compile and link steps. However, we can't mess with CFLAGS in the platform template file without confusing configure's logic for choosing default CFLAGS.) Back-patch of 49407dc32 into all supported branches. Report and patch by James Hilliard (some cosmetic mods by me) Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9e9a31bd009663bcdd5e676d6012ee691d8944b6 Modified Files -- configure | 2 ++ configure.in| 2 ++ src/template/darwin | 1 + 3 files changed, 5 insertions(+)
pgsql: On macOS, use -isysroot in link steps as well as compile steps.
On macOS, use -isysroot in link steps as well as compile steps. We previously put the -isysroot switch only into CPPFLAGS, theorizing that it was only needed to find the right copies of include files. However, it seems that we also need to use it while linking programs, to find the right stub ".tbd" files for libraries. We got away without that up to now, but apparently that was mostly luck. It may also be that failures are only observed when the Xcode version is noticeably out of sync with the host macOS version; the case that's prompting action right now is that builds fail when using latest Xcode (12.2) on macOS Catalina, even though it's fine on Big Sur. Hence, add -isysroot to LDFLAGS as well. (It seems that the more common practice is to put it in CFLAGS, whence it'd be included at both compile and link steps. However, we can't mess with CFLAGS in the platform template file without confusing configure's logic for choosing default CFLAGS.) Back-patch of 49407dc32 into all supported branches. Report and patch by James Hilliard (some cosmetic mods by me) Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/153bf8d2044a1bab07c151ae2b3c306c0b138161 Modified Files -- configure | 2 ++ configure.in| 2 ++ src/template/darwin | 1 + 3 files changed, 5 insertions(+)
pgsql: Emit log when restore_command succeeds but archived file faills
Emit log when restore_command succeeds but archived file faills to be restored. Previously, when restore_command claimed to succeed but failed to restore the file with the right name, for example, due to mis-configuration of restore_command, no log message was reported. Then the recovery failed later with an error message not directly related to the issue. This commit changes the recovery so that a log message is emitted in this error case. This would enable us to investigate what happened in this case more easily. Author: Jeff Janes, Fujii Masao Reviewed-by: Pavel Borisov, Kyotaro Horiguchi Discussion: https://postgr.es/m/CAMkU=1xkFs3Omp4JR4wMYWdam_KLuj6LXnTYfU8u3T0h=pl...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a4ef0329c27156dca81714854599e7d82becb17f Modified Files -- src/backend/access/transam/xlogarchive.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-)
