pgsql: Avoid ERRCODE_INTERNAL_ERROR in oracle_compat.c functions.
Avoid ERRCODE_INTERNAL_ERROR in oracle_compat.c functions. repeat() checked for integer overflow during its calculation of the required output space, but it just passed the resulting integer to palloc(). This meant that result sizes between 1GB and 2GB led to ERRCODE_INTERNAL_ERROR, "invalid memory alloc request size" rather than ERRCODE_PROGRAM_LIMIT_EXCEEDED, "requested length too large". That seems like a bit of a wart, so add an explicit AllocSizeIsValid check to make these error cases uniform. Do likewise in the sibling functions lpad() etc. While we're here, also modernize their overflow checks to use pg_mul_s32_overflow() etc instead of expensive divisions. Per complaint from Japin Li. This is basically cosmetic, so I don't feel a need to back-patch. Discussion: https://postgr.es/m/me3p282mb16676ed32167189cb0462173b6...@me3p282mb1667.ausp282.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6217053f4e856159442629bd50c583ce3e4bc1fb Modified Files -- src/backend/utils/adt/oracle_compat.c | 43 +++ 1 file changed, 24 insertions(+), 19 deletions(-)
pgsql: In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff.
In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff. Foreign tables can be partitioned, but previous documentation commits left the syntax synopsis both incomplete and incorrect. Justin Pryzby and Amit Langote Discussion: http://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4368ef21895968884bbba4127f6aed4ce5cb5218 Modified Files -- doc/src/sgml/ref/create_foreign_table.sgml | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff.
In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff. Foreign tables can be partitioned, but previous documentation commits left the syntax synopsis both incomplete and incorrect. Justin Pryzby and Amit Langote Discussion: http://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/036cffbcae9b8e1b8a17ebe5203cb596f82b5989 Modified Files -- doc/src/sgml/ref/create_foreign_table.sgml | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff.
In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff. Foreign tables can be partitioned, but previous documentation commits left the syntax synopsis both incomplete and incorrect. Justin Pryzby and Amit Langote Discussion: http://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d605eba0904b7c0cfe8c3d994df56fb9eaeb7989 Modified Files -- doc/src/sgml/ref/create_foreign_table.sgml | 9 - 1 file changed, 8 insertions(+), 1 deletion(-)
pgsql: In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff.
In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff. Foreign tables can be partitioned, but previous documentation commits left the syntax synopsis both incomplete and incorrect. Justin Pryzby and Amit Langote Discussion: http://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0fab33916789eba84a1646a33da70dcb261fbd74 Modified Files -- doc/src/sgml/ref/create_foreign_table.sgml | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff.
In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff. Foreign tables can be partitioned, but previous documentation commits left the syntax synopsis both incomplete and incorrect. Justin Pryzby and Amit Langote Discussion: http://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ce21a36cf837083cb41521aff035d9c1310f0f66 Modified Files -- doc/src/sgml/ref/create_foreign_table.sgml | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff.
In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff. Foreign tables can be partitioned, but previous documentation commits left the syntax synopsis both incomplete and incorrect. Justin Pryzby and Amit Langote Discussion: http://postgr.es/m/[email protected] Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a5fc06bf31352fc57cb34ccbf2ca18214118ab9b Modified Files -- doc/src/sgml/ref/create_foreign_table.sgml | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)
pgsql: Remove misguided SSL key file ownership check in libpq.
Remove misguided SSL key file ownership check in libpq. Commits a59c79564 et al. tried to sync libpq's SSL key file permissions checks with what we've used for years in the backend. We did not intend to create any new failure cases, but it turns out we did: restricting the key file's ownership breaks cases where the client is allowed to read a key file despite not having the identical UID. In particular a client running as root used to be able to read someone else's key file; and having seen that I suspect that there are other, less-dubious use cases that this restriction breaks on some platforms. We don't really need an ownership check, since if we can read the key file despite its having restricted permissions, it must have the right ownership --- under normal conditions anyway, and the point of this patch is that any additional corner cases where that works should be deemed allowable, as they have been historically. Hence, just drop the ownership check, and rearrange the permissions check to get rid of its faulty assumption that geteuid() can't be zero. (Note that the comparable backend-side code doesn't have to cater for geteuid() == 0, since the server rejects that very early on.) This does have the end result that the permissions safety check used for a root user's private key file is weaker than that used for anyone else's. While odd, root really ought to know what she's doing with file permissions, so I think this is acceptable. Per report from Yogendra Suralkar. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/mw3pr15mb3931df96896dc36d21afd47ca3...@mw3pr15mb3931.namprd15.prod.outlook.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a44bc8b8f421d8696eaa796884acb6ed6cc6c670 Modified Files -- src/backend/libpq/be-secure-common.c | 5 +++-- src/interfaces/libpq/fe-secure-openssl.c | 34 2 files changed, 20 insertions(+), 19 deletions(-)
pgsql: Remove misguided SSL key file ownership check in libpq.
Remove misguided SSL key file ownership check in libpq. Commits a59c79564 et al. tried to sync libpq's SSL key file permissions checks with what we've used for years in the backend. We did not intend to create any new failure cases, but it turns out we did: restricting the key file's ownership breaks cases where the client is allowed to read a key file despite not having the identical UID. In particular a client running as root used to be able to read someone else's key file; and having seen that I suspect that there are other, less-dubious use cases that this restriction breaks on some platforms. We don't really need an ownership check, since if we can read the key file despite its having restricted permissions, it must have the right ownership --- under normal conditions anyway, and the point of this patch is that any additional corner cases where that works should be deemed allowable, as they have been historically. Hence, just drop the ownership check, and rearrange the permissions check to get rid of its faulty assumption that geteuid() can't be zero. (Note that the comparable backend-side code doesn't have to cater for geteuid() == 0, since the server rejects that very early on.) This does have the end result that the permissions safety check used for a root user's private key file is weaker than that used for anyone else's. While odd, root really ought to know what she's doing with file permissions, so I think this is acceptable. Per report from Yogendra Suralkar. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/mw3pr15mb3931df96896dc36d21afd47ca3...@mw3pr15mb3931.namprd15.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2b65de7fc296bb5060c8d4ae8cb680f71364fbe0 Modified Files -- src/backend/libpq/be-secure-common.c | 5 +++-- src/interfaces/libpq/fe-secure-openssl.c | 34 2 files changed, 20 insertions(+), 19 deletions(-)
pgsql: Remove misguided SSL key file ownership check in libpq.
Remove misguided SSL key file ownership check in libpq. Commits a59c79564 et al. tried to sync libpq's SSL key file permissions checks with what we've used for years in the backend. We did not intend to create any new failure cases, but it turns out we did: restricting the key file's ownership breaks cases where the client is allowed to read a key file despite not having the identical UID. In particular a client running as root used to be able to read someone else's key file; and having seen that I suspect that there are other, less-dubious use cases that this restriction breaks on some platforms. We don't really need an ownership check, since if we can read the key file despite its having restricted permissions, it must have the right ownership --- under normal conditions anyway, and the point of this patch is that any additional corner cases where that works should be deemed allowable, as they have been historically. Hence, just drop the ownership check, and rearrange the permissions check to get rid of its faulty assumption that geteuid() can't be zero. (Note that the comparable backend-side code doesn't have to cater for geteuid() == 0, since the server rejects that very early on.) This does have the end result that the permissions safety check used for a root user's private key file is weaker than that used for anyone else's. While odd, root really ought to know what she's doing with file permissions, so I think this is acceptable. Per report from Yogendra Suralkar. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/mw3pr15mb3931df96896dc36d21afd47ca3...@mw3pr15mb3931.namprd15.prod.outlook.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ef54a65762f02eaeb8b2b30414ace55b203bce01 Modified Files -- src/backend/libpq/be-secure-openssl.c| 5 +++-- src/interfaces/libpq/fe-secure-openssl.c | 34 2 files changed, 20 insertions(+), 19 deletions(-)
pgsql: Remove misguided SSL key file ownership check in libpq.
Remove misguided SSL key file ownership check in libpq. Commits a59c79564 et al. tried to sync libpq's SSL key file permissions checks with what we've used for years in the backend. We did not intend to create any new failure cases, but it turns out we did: restricting the key file's ownership breaks cases where the client is allowed to read a key file despite not having the identical UID. In particular a client running as root used to be able to read someone else's key file; and having seen that I suspect that there are other, less-dubious use cases that this restriction breaks on some platforms. We don't really need an ownership check, since if we can read the key file despite its having restricted permissions, it must have the right ownership --- under normal conditions anyway, and the point of this patch is that any additional corner cases where that works should be deemed allowable, as they have been historically. Hence, just drop the ownership check, and rearrange the permissions check to get rid of its faulty assumption that geteuid() can't be zero. (Note that the comparable backend-side code doesn't have to cater for geteuid() == 0, since the server rejects that very early on.) This does have the end result that the permissions safety check used for a root user's private key file is weaker than that used for anyone else's. While odd, root really ought to know what she's doing with file permissions, so I think this is acceptable. Per report from Yogendra Suralkar. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/mw3pr15mb3931df96896dc36d21afd47ca3...@mw3pr15mb3931.namprd15.prod.outlook.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b4be4a082bde8b4f3caca6fa3127af005720f2d8 Modified Files -- src/backend/libpq/be-secure-common.c | 5 +++-- src/interfaces/libpq/fe-secure-openssl.c | 34 2 files changed, 20 insertions(+), 19 deletions(-)
pgsql: Remove misguided SSL key file ownership check in libpq.
Remove misguided SSL key file ownership check in libpq. Commits a59c79564 et al. tried to sync libpq's SSL key file permissions checks with what we've used for years in the backend. We did not intend to create any new failure cases, but it turns out we did: restricting the key file's ownership breaks cases where the client is allowed to read a key file despite not having the identical UID. In particular a client running as root used to be able to read someone else's key file; and having seen that I suspect that there are other, less-dubious use cases that this restriction breaks on some platforms. We don't really need an ownership check, since if we can read the key file despite its having restricted permissions, it must have the right ownership --- under normal conditions anyway, and the point of this patch is that any additional corner cases where that works should be deemed allowable, as they have been historically. Hence, just drop the ownership check, and rearrange the permissions check to get rid of its faulty assumption that geteuid() can't be zero. (Note that the comparable backend-side code doesn't have to cater for geteuid() == 0, since the server rejects that very early on.) This does have the end result that the permissions safety check used for a root user's private key file is weaker than that used for anyone else's. While odd, root really ought to know what she's doing with file permissions, so I think this is acceptable. Per report from Yogendra Suralkar. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/mw3pr15mb3931df96896dc36d21afd47ca3...@mw3pr15mb3931.namprd15.prod.outlook.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9e3dbc6fd9a38cd7c72289f7facd639976484e45 Modified Files -- src/backend/libpq/be-secure-common.c | 5 +++-- src/interfaces/libpq/fe-secure-openssl.c | 34 2 files changed, 20 insertions(+), 19 deletions(-)
pgsql: Remove misguided SSL key file ownership check in libpq.
Remove misguided SSL key file ownership check in libpq. Commits a59c79564 et al. tried to sync libpq's SSL key file permissions checks with what we've used for years in the backend. We did not intend to create any new failure cases, but it turns out we did: restricting the key file's ownership breaks cases where the client is allowed to read a key file despite not having the identical UID. In particular a client running as root used to be able to read someone else's key file; and having seen that I suspect that there are other, less-dubious use cases that this restriction breaks on some platforms. We don't really need an ownership check, since if we can read the key file despite its having restricted permissions, it must have the right ownership --- under normal conditions anyway, and the point of this patch is that any additional corner cases where that works should be deemed allowable, as they have been historically. Hence, just drop the ownership check, and rearrange the permissions check to get rid of its faulty assumption that geteuid() can't be zero. (Note that the comparable backend-side code doesn't have to cater for geteuid() == 0, since the server rejects that very early on.) This does have the end result that the permissions safety check used for a root user's private key file is weaker than that used for anyone else's. While odd, root really ought to know what she's doing with file permissions, so I think this is acceptable. Per report from Yogendra Suralkar. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/mw3pr15mb3931df96896dc36d21afd47ca3...@mw3pr15mb3931.namprd15.prod.outlook.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/01ab9fb7dee5f9445bae94a942afb6ee9bcccd4f Modified Files -- src/backend/libpq/be-secure-common.c | 5 +++-- src/interfaces/libpq/fe-secure-openssl.c | 34 2 files changed, 20 insertions(+), 19 deletions(-)
pgsql: Teach remove_unused_subquery_outputs about window run conditions
Teach remove_unused_subquery_outputs about window run conditions 9d9c02ccd added code to allow the executor to take shortcuts when quals on monotonic window functions guaranteed that once the qual became false it could never become true again. When possible, baserestrictinfo quals are converted to become these quals, which we call run conditions. Unfortunately, in 9d9c02ccd, I forgot to update remove_unused_subquery_outputs to teach it about these run conditions. This could cause a WindowFunc column which was unused in the target list but referenced by an upper-level WHERE clause to be removed from the subquery when the qual in the WHERE clause was converted into a window run condition. Because of this, the entire WindowClause would be removed from the query resulting in additional rows making it into the resultset when they should have been filtered out by the WHERE clause. Here we fix this by recording which target list items in the subquery have run conditions. That gets passed along to remove_unused_subquery_outputs to tell it not to remove these items from the target list. Bug: #17495 Reported-by: Jeremy Evans Reviewed-by: Richard Guo Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3e9abd2eb1b1f6863250f060290f514f30ce8044 Modified Files -- src/backend/optimizer/path/allpaths.c | 50 +++ src/backend/parser/parse_clause.c | 1 + src/test/regress/expected/window.out | 19 + src/test/regress/sql/window.sql | 10 +++ 4 files changed, 69 insertions(+), 11 deletions(-)
