pgsql: In pg_restore's dump_lo_buf(), work a little harder on error han
In pg_restore's dump_lo_buf(), work a little harder on error handling. Failure to write data to a large object during restore led to an ugly and uninformative error message. To add insult to injury, it then fatal'd out, where other SQL-level errors usually result in pressing on. Report the underlying error condition, rather than just giving not-very- useful byte counts, and use warn_or_exit_horribly() so as to adhere to pg_restore's general policy about whether to continue or not. Also recognize that lo_write() returns int not size_t. Per report from Justin Pryzby, though I didn't use his patch. Given the lack of comparable complaints, I'm not sure this is worth back-patching. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/929c69aa1970b3ae30bbb5a159b9dc530ec34d5c Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)
pgsql: Update the Winsock API version requested by libpq.
Update the Winsock API version requested by libpq. According to Microsoft's documentation, 2.2 has been the current version since Windows 98 or so. Moreover, that's what the Postgres backend has been requesting since 2004 (cf commit 4cdf51e64). So there seems no reason for libpq to keep asking for 1.1. Bring thread_test along, too, so that we're uniformly asking for 2.2 in all our WSAStartup calls. It's not clear whether there's any point in back-patching this, so for now I didn't. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d5a9a661fcd2f5db037274157f931863a52004fd Modified Files -- src/interfaces/libpq/fe-connect.c | 2 +- src/test/thread/thread_test.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Prevent overly large and NaN row estimates in relations
Prevent overly large and NaN row estimates in relations Given a query with enough joins, it was possible that the query planner, after multiplying the row estimates with the join selectivity that the estimated number of rows would exceed the limits of the double data type and become infinite. To give an indication on how extreme a case is required to hit this, the particular example case reported required 379 joins to a table without any statistics, which resulted in the 1.0/DEFAULT_NUM_DISTINCT being used for the join selectivity. This eventually caused the row estimates to go infinite and resulted in an assert failure in initial_cost_mergejoin() where the infinite row estimated was multiplied by an outerstartsel of 0.0 resulting in NaN. The failing assert verified that NaN <= Inf, which is false. To get around this we use clamp_row_est() to cap row estimates at a maximum of 1e100. This value is thought to be low enough that costs derived from it would remain within the bounds of what the double type can represent. Aside from fixing the failing Assert, this also has the added benefit of making it so add_path() will still receive proper numerical values as costs which will allow it to make more sane choices when determining the cheaper path in extreme cases such as the one described above. Additionally, we also get rid of the isnan() checks in the join costing functions. The actual case which originally triggered those checks to be added in the first place never made it to the mailing lists. It seems likely that the new code being added to clamp_row_est() will result in those becoming checks redundant, so just remove them. The fairly harmless assert failure problem does also exist in the backbranches, however, a more minimalistic fix will be applied there. Reported-by: Onder Kalaci Reviewed-by: Tom Lane Discussion: https://postgr.es/m/dm6pr21mb1211ff360183bca901b27f04d8...@dm6pr21mb1211.namprd21.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a90c950fc7fd8796daa8c7948e7046bceb272894 Modified Files -- src/backend/optimizer/path/costsize.c | 35 ++- 1 file changed, 22 insertions(+), 13 deletions(-)
pgsql: Fix potential memory leak in pgcrypto
Fix potential memory leak in pgcrypto When allocating a EVP context, it would have been possible to leak some memory allocated directly by OpenSSL, that PostgreSQL lost track of if the initialization of the context allocated failed. The cleanup can be done with EVP_MD_CTX_destroy(). Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree equivalent implementations for older versions since ce9b75d (code removed with 9b7cd59a as of 10~). However, in 9.5 and 9.6, the existing code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without an equivalent implementation when building the tree with OpenSSL 0.9.6 or older, meaning that this code is in reality broken with such versions since it got introduced in e2838c5. As we have heard no complains about that, it does not seem worth bothering with in 9.5 and 9.6, so I have left that out for simplicity. Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9141390813e0bbbe315313b232e027fa977c3b21 Modified Files -- contrib/pgcrypto/openssl.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Fix potential memory leak in pgcrypto
Fix potential memory leak in pgcrypto When allocating a EVP context, it would have been possible to leak some memory allocated directly by OpenSSL, that PostgreSQL lost track of if the initialization of the context allocated failed. The cleanup can be done with EVP_MD_CTX_destroy(). Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree equivalent implementations for older versions since ce9b75d (code removed with 9b7cd59a as of 10~). However, in 9.5 and 9.6, the existing code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without an equivalent implementation when building the tree with OpenSSL 0.9.6 or older, meaning that this code is in reality broken with such versions since it got introduced in e2838c5. As we have heard no complains about that, it does not seem worth bothering with in 9.5 and 9.6, so I have left that out for simplicity. Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e8d36f9ece5e48e6252f9ba3dc01c51755036f9a Modified Files -- contrib/pgcrypto/openssl.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Fix potential memory leak in pgcrypto
Fix potential memory leak in pgcrypto When allocating a EVP context, it would have been possible to leak some memory allocated directly by OpenSSL, that PostgreSQL lost track of if the initialization of the context allocated failed. The cleanup can be done with EVP_MD_CTX_destroy(). Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree equivalent implementations for older versions since ce9b75d (code removed with 9b7cd59a as of 10~). However, in 9.5 and 9.6, the existing code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without an equivalent implementation when building the tree with OpenSSL 0.9.6 or older, meaning that this code is in reality broken with such versions since it got introduced in e2838c5. As we have heard no complains about that, it does not seem worth bothering with in 9.5 and 9.6, so I have left that out for simplicity. Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/994a02f7f77c760db5c28aa9f34c7e7fd88993cf Modified Files -- contrib/pgcrypto/openssl.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Fix potential memory leak in pgcrypto
Fix potential memory leak in pgcrypto When allocating a EVP context, it would have been possible to leak some memory allocated directly by OpenSSL, that PostgreSQL lost track of if the initialization of the context allocated failed. The cleanup can be done with EVP_MD_CTX_destroy(). Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree equivalent implementations for older versions since ce9b75d (code removed with 9b7cd59a as of 10~). However, in 9.5 and 9.6, the existing code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without an equivalent implementation when building the tree with OpenSSL 0.9.6 or older, meaning that this code is in reality broken with such versions since it got introduced in e2838c5. As we have heard no complains about that, it does not seem worth bothering with in 9.5 and 9.6, so I have left that out for simplicity. Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1bd9b2b2369608de7763b3947af2f59292152268 Modified Files -- contrib/pgcrypto/openssl.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Fix potential memory leak in pgcrypto
Fix potential memory leak in pgcrypto When allocating a EVP context, it would have been possible to leak some memory allocated directly by OpenSSL, that PostgreSQL lost track of if the initialization of the context allocated failed. The cleanup can be done with EVP_MD_CTX_destroy(). Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree equivalent implementations for older versions since ce9b75d (code removed with 9b7cd59a as of 10~). However, in 9.5 and 9.6, the existing code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without an equivalent implementation when building the tree with OpenSSL 0.9.6 or older, meaning that this code is in reality broken with such versions since it got introduced in e2838c5. As we have heard no complains about that, it does not seem worth bothering with in 9.5 and 9.6, so I have left that out for simplicity. Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ca2a12c935f75fb56c3b14527d6f2ff6f549ea85 Modified Files -- contrib/pgcrypto/openssl.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Fix potential memory leak in pgcrypto
Fix potential memory leak in pgcrypto When allocating a EVP context, it would have been possible to leak some memory allocated directly by OpenSSL, that PostgreSQL lost track of if the initialization of the context allocated failed. The cleanup can be done with EVP_MD_CTX_destroy(). Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree equivalent implementations for older versions since ce9b75d (code removed with 9b7cd59a as of 10~). However, in 9.5 and 9.6, the existing code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without an equivalent implementation when building the tree with OpenSSL 0.9.6 or older, meaning that this code is in reality broken with such versions since it got introduced in e2838c5. As we have heard no complains about that, it does not seem worth bothering with in 9.5 and 9.6, so I have left that out for simplicity. Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/57bdf29dd5f66bda9bcb538b6911b1accd89f47e Modified Files -- contrib/pgcrypto/openssl.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Fix potential memory leak in pgcrypto
Fix potential memory leak in pgcrypto When allocating a EVP context, it would have been possible to leak some memory allocated directly by OpenSSL, that PostgreSQL lost track of if the initialization of the context allocated failed. The cleanup can be done with EVP_MD_CTX_destroy(). Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree equivalent implementations for older versions since ce9b75d (code removed with 9b7cd59a as of 10~). However, in 9.5 and 9.6, the existing code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without an equivalent implementation when building the tree with OpenSSL 0.9.6 or older, meaning that this code is in reality broken with such versions since it got introduced in e2838c5. As we have heard no complains about that, it does not seem worth bothering with in 9.5 and 9.6, so I have left that out for simplicity. Author: Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/099238322cf80dc0ea11d1cbd84e78fbf95f48e5 Modified Files -- contrib/pgcrypto/openssl.c | 1 + 1 file changed, 1 insertion(+)
pgsql: Change the docs for PARALLEL option of Vacuum.
Change the docs for PARALLEL option of Vacuum. The rules to choose the number of parallel workers to perform parallel vacuum operation were not clearly specified. Reported-by: Peter Eisentraut Author: Amit Kapila Backpatch-through: 13, where it was introduced Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/560d260d7852dc54a8c587c1b388843e8c433bc8 Modified Files -- doc/src/sgml/ref/vacuum.sgml | 32 1 file changed, 16 insertions(+), 16 deletions(-)
pgsql: Change the docs for PARALLEL option of Vacuum.
Change the docs for PARALLEL option of Vacuum. The rules to choose the number of parallel workers to perform parallel vacuum operation were not clearly specified. Reported-by: Peter Eisentraut Author: Amit Kapila Backpatch-through: 13, where it was introduced Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/99ae342fc4ffe5f9a6ec7f540c5a31fb483b06e6 Modified Files -- doc/src/sgml/ref/vacuum.sgml | 32 1 file changed, 16 insertions(+), 16 deletions(-)
pgsql: Improve whitespace
Improve whitespace The SQL file was using a mix of tabs and spaces inconsistently. Convert all to spaces and adjust indentation accordingly. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/afa0d53d4de6d2f43fbc0a76c88dceb22ba65e86 Modified Files -- src/test/regress/expected/hash_func.out | 134 src/test/regress/sql/hash_func.sql | 134 2 files changed, 134 insertions(+), 134 deletions(-)
