pgsql: Disable command echo in pg_upgrade-created windows scripts
Disable command echo in pg_upgrade-created windows scripts This makes them more like the Unix equivalents. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/91d76613b7ec75b6642accaff91dc7d657e549e9 Modified Files -- src/bin/pg_upgrade/pg_upgrade.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Use the "pg_temp" schema alias in EXPLAIN and related output.
Use the "pg_temp" schema alias in EXPLAIN and related output. This patch causes EXPLAIN output to refer to objects that are in the current session's temp schema with the "pg_temp" schema alias rather than that schema's actual name. This is useful for our own testing purposes since it will stabilize EXPLAIN VERBOSE output for such cases, allowing us to use that in regression tests. It should be less confusing for end users too. Since ruleutils.c needs to change behavior for this, the change also leaks into a few other users of ruleutils.c, for example pg_get_viewdef(). AFAICS that won't cause any problems. We did find that aggressively trying to change this behavior across-the-board would cause issues, but as long as "pg_temp" only appears within generated SQL text, I think it'll be fine. Along the way, make get_namespace_name_or_temp conform to the same API as get_namespace_name, ie that it returns a palloc'd string or NULL. The current behavior hasn't caused any bugs since no callers attempt to pfree the result, but if it gets more widespread usage that could become a problem. Amul Sul, reviewed and extended by me Discussion: https://postgr.es/m/CAAJ_b97W=qagmag9ahwnbmx3ueysnkxwl+ovw1_e1d3btgw...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/48c5c9068211e0a04fd9553c8714b2821ed3ad17 Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 2 +- src/backend/commands/explain.c| 5 ++--- src/backend/utils/adt/ruleutils.c | 20 ++-- src/backend/utils/cache/lsyscache.c | 2 +- src/test/regress/expected/explain.out | 13 + src/test/regress/sql/explain.sql | 9 + 6 files changed, 36 insertions(+), 15 deletions(-)
pgsql: In event triggers, use "pg_temp" only for our own temp schema.
In event triggers, use "pg_temp" only for our own temp schema. pg_event_trigger_ddl_commands used "pg_temp" to refer to any temp schema, not only that of the current backend. This seems like overreach. It's somewhat unlikely that DDL commands would refer to temp objects of other sessions to begin with, but if they do, "pg_temp" would be a most misleading way to display the action. While this seems like a bug, it's not quite out of the realm of possibility that somebody out there is expecting the current behavior. Hence, fix in HEAD, but don't back-patch. Discussion: https://postgr.es/m/CAAJ_b97W=qagmag9ahwnbmx3ueysnkxwl+ovw1_e1d3btgw...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/024515cac50e246d92bbe67e9de4da0f302972ef Modified Files -- src/backend/commands/event_trigger.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-)
Re: pgsql: Allow numeric scale to be negative or greater than precision.
This is for migration? Or does it mean very small values now occupy less space since we store fewer zeros? Thanks On Mon, 26 Jul 2021 at 14:17, Dean Rasheed wrote: > > Allow numeric scale to be negative or greater than precision. > > Formerly, when specifying NUMERIC(precision, scale), the scale had to > be in the range [0, precision], which was per SQL spec. This commit > extends the range of allowed scales to [-1000, 1000], independent of > the precision (whose valid range remains [1, 1000]). > > A negative scale implies rounding before the decimal point. For > example, a column might be declared with a scale of -3 to round values > to the nearest thousand. Note that the display scale remains > non-negative, so in this case the display scale will be zero, and all > digits before the decimal point will be displayed. > > A scale greater than the precision supports fractional values with > zeros immediately after the decimal point. > > Take the opportunity to tidy up the code that packs, unpacks and > validates the contents of a typmod integer, encapsulating it in a > small set of new inline functions. > > Bump the catversion because the allowed contents of atttypmod have > changed for numeric columns. This isn't a change that requires a > re-initdb, but negative scale values in the typmod would confuse old > backends. > > Dean Rasheed, with additional improvements by Tom Lane. Reviewed by > Tom Lane. > > Discussion: > https://postgr.es/m/caezatcwdnlgpkihmurf8nfofp0rftakj7kty6gczopnmfuo...@mail.gmail.com > > Branch > -- > master > > Details > --- > https://git.postgresql.org/pg/commitdiff/085f931f52494e1f304e35571924efa6fcdc2b44 > > Modified Files > -- > doc/src/sgml/datatype.sgml | 48 ++- > src/backend/utils/adt/numeric.c| 130 + > src/include/catalog/catversion.h | 2 +- > src/include/utils/numeric.h| 16 +++- > src/test/regress/expected/numeric.out | 63 ++ > src/test/regress/expected/sanity_check.out | 1 + > src/test/regress/sql/numeric.sql | 34 > 7 files changed, 251 insertions(+), 43 deletions(-) > -- Simon Riggshttp://www.EnterpriseDB.com/
Re: pgsql: Allow numeric scale to be negative or greater than precision.
Simon Riggs writes: > This is for migration? Yeah, compatibility with some other DBMSes that allow this. > Or does it mean very small values now occupy less space since we store > fewer zeros? It won't affect space consumption at all, as NUMERIC has never stored leading or trailing zeroes. (Modulo the fact that "zero" here means a base-NDIGIT digit.) regards, tom lane
pgsql: Avoid using ambiguous word "non-negative" in error messages.
Avoid using ambiguous word "non-negative" in error messages. The error messages using the word "non-negative" are confusing because it's ambiguous about whether it accepts zero or not. This commit improves those error messages by replacing it with less ambiguous word like "greater than zero" or "greater than or equal to zero". Also this commit added the note about the word "non-negative" to the error message style guide, to help writing the new error messages. When postgres_fdw option fetch_size was set to zero, previously the error message "fetch_size requires a non-negative integer value" was reported. This error message was outright buggy. Therefore back-patch to all supported versions where such buggy error message could be thrown. Reported-by: Hou Zhijie Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/os0pr01mb5716415335a06b489f1b3a8194...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0e1275fb073cbbff2185f4067d67785e56941e50 Modified Files -- contrib/postgres_fdw/option.c | 9 ++--- doc/src/sgml/sources.sgml | 10 ++ src/backend/partitioning/partbounds.c | 4 ++-- src/backend/utils/adt/tsquery_op.c | 2 +- src/test/modules/test_shm_mq/test.c | 10 +- src/test/regress/expected/hash_part.out | 4 ++-- 6 files changed, 26 insertions(+), 13 deletions(-)
pgsql: Avoid using ambiguous word "non-negative" in error messages.
Avoid using ambiguous word "non-negative" in error messages. The error messages using the word "non-negative" are confusing because it's ambiguous about whether it accepts zero or not. This commit improves those error messages by replacing it with less ambiguous word like "greater than zero" or "greater than or equal to zero". Also this commit added the note about the word "non-negative" to the error message style guide, to help writing the new error messages. When postgres_fdw option fetch_size was set to zero, previously the error message "fetch_size requires a non-negative integer value" was reported. This error message was outright buggy. Therefore back-patch to all supported versions where such buggy error message could be thrown. Reported-by: Hou Zhijie Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/os0pr01mb5716415335a06b489f1b3a8194...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fd90f6ba7a75f51d14dac27219bb3755b893e251 Modified Files -- contrib/postgres_fdw/option.c | 9 ++--- doc/src/sgml/sources.sgml | 10 ++ src/backend/partitioning/partbounds.c | 4 ++-- src/backend/utils/adt/tsquery_op.c | 2 +- src/test/modules/test_shm_mq/test.c | 10 +- src/test/regress/expected/hash_part.out | 4 ++-- 6 files changed, 26 insertions(+), 13 deletions(-)
pgsql: Avoid using ambiguous word "non-negative" in error messages.
Avoid using ambiguous word "non-negative" in error messages. The error messages using the word "non-negative" are confusing because it's ambiguous about whether it accepts zero or not. This commit improves those error messages by replacing it with less ambiguous word like "greater than zero" or "greater than or equal to zero". Also this commit added the note about the word "non-negative" to the error message style guide, to help writing the new error messages. When postgres_fdw option fetch_size was set to zero, previously the error message "fetch_size requires a non-negative integer value" was reported. This error message was outright buggy. Therefore back-patch to all supported versions where such buggy error message could be thrown. Reported-by: Hou Zhijie Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/os0pr01mb5716415335a06b489f1b3a8194...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/92913fc290f3adb3fe937485474a11ac6708e4b0 Modified Files -- contrib/postgres_fdw/option.c | 13 - doc/src/sgml/sources.sgml | 10 ++ src/backend/partitioning/partbounds.c | 4 ++-- src/backend/utils/adt/tsquery_op.c | 2 +- src/test/modules/test_shm_mq/test.c | 10 +- src/test/regress/expected/hash_part.out | 4 ++-- 6 files changed, 28 insertions(+), 15 deletions(-)
pgsql: Avoid using ambiguous word "non-negative" in error messages.
Avoid using ambiguous word "non-negative" in error messages. The error messages using the word "non-negative" are confusing because it's ambiguous about whether it accepts zero or not. This commit improves those error messages by replacing it with less ambiguous word like "greater than zero" or "greater than or equal to zero". Also this commit added the note about the word "non-negative" to the error message style guide, to help writing the new error messages. When postgres_fdw option fetch_size was set to zero, previously the error message "fetch_size requires a non-negative integer value" was reported. This error message was outright buggy. Therefore back-patch to all supported versions where such buggy error message could be thrown. Reported-by: Hou Zhijie Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/os0pr01mb5716415335a06b489f1b3a8194...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/de87c481f635953e84e7d3b404e15700301bcdac Modified Files -- contrib/postgres_fdw/option.c | 13 - doc/src/sgml/sources.sgml | 10 ++ src/backend/partitioning/partbounds.c | 4 ++-- src/backend/utils/adt/tsquery_op.c | 2 +- src/test/modules/test_shm_mq/test.c | 10 +- src/test/regress/expected/hash_part.out | 4 ++-- 6 files changed, 28 insertions(+), 15 deletions(-)
pgsql: Avoid using ambiguous word "non-negative" in error messages.
Avoid using ambiguous word "non-negative" in error messages. The error messages using the word "non-negative" are confusing because it's ambiguous about whether it accepts zero or not. This commit improves those error messages by replacing it with less ambiguous word like "greater than zero" or "greater than or equal to zero". Also this commit added the note about the word "non-negative" to the error message style guide, to help writing the new error messages. When postgres_fdw option fetch_size was set to zero, previously the error message "fetch_size requires a non-negative integer value" was reported. This error message was outright buggy. Therefore back-patch to all supported versions where such buggy error message could be thrown. Reported-by: Hou Zhijie Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/os0pr01mb5716415335a06b489f1b3a8194...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/42e6b5ccb777a8d18ecc26140d4044af5bccc9b3 Modified Files -- contrib/postgres_fdw/option.c | 13 - doc/src/sgml/sources.sgml | 10 ++ src/backend/partitioning/partbounds.c | 4 ++-- src/backend/utils/adt/tsquery_op.c | 2 +- src/test/modules/test_shm_mq/test.c | 10 +- src/test/regress/expected/hash_part.out | 4 ++-- 6 files changed, 28 insertions(+), 15 deletions(-)
pgsql: Avoid using ambiguous word "non-negative" in error messages.
Avoid using ambiguous word "non-negative" in error messages. The error messages using the word "non-negative" are confusing because it's ambiguous about whether it accepts zero or not. This commit improves those error messages by replacing it with less ambiguous word like "greater than zero" or "greater than or equal to zero". Also this commit added the note about the word "non-negative" to the error message style guide, to help writing the new error messages. When postgres_fdw option fetch_size was set to zero, previously the error message "fetch_size requires a non-negative integer value" was reported. This error message was outright buggy. Therefore back-patch to all supported versions where such buggy error message could be thrown. Reported-by: Hou Zhijie Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/os0pr01mb5716415335a06b489f1b3a8194...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a84f95ffddbf9bfcf20f7e3b463e10ba1ec0b9f5 Modified Files -- contrib/postgres_fdw/option.c | 13 - doc/src/sgml/sources.sgml | 10 ++ src/backend/utils/adt/tsquery_op.c | 2 +- src/test/modules/test_shm_mq/test.c | 10 +- 4 files changed, 24 insertions(+), 11 deletions(-)
pgsql: Avoid using ambiguous word "non-negative" in error messages.
Avoid using ambiguous word "non-negative" in error messages. The error messages using the word "non-negative" are confusing because it's ambiguous about whether it accepts zero or not. This commit improves those error messages by replacing it with less ambiguous word like "greater than zero" or "greater than or equal to zero". Also this commit added the note about the word "non-negative" to the error message style guide, to help writing the new error messages. When postgres_fdw option fetch_size was set to zero, previously the error message "fetch_size requires a non-negative integer value" was reported. This error message was outright buggy. Therefore back-patch to all supported versions where such buggy error message could be thrown. Reported-by: Hou Zhijie Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/os0pr01mb5716415335a06b489f1b3a8194...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/78c21d79d72aa38cfe4a16b232aaf9d723b20378 Modified Files -- contrib/postgres_fdw/option.c | 13 - doc/src/sgml/sources.sgml | 10 ++ src/backend/utils/adt/tsquery_op.c | 2 +- src/test/modules/test_shm_mq/test.c | 10 +- 4 files changed, 24 insertions(+), 11 deletions(-)
pgsql: Stabilize output of new regression test.
Stabilize output of new regression test. Commit 48c5c9068 failed to allow for buildfarm animals that force jit = on. I'm surprised that this hasn't come up elsewhere in explain.sql, so turn it off for that whole test script not just the one new test case. Per buildfarm. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/674f6fe8e65a37289432fa373e5d742a36751ae8 Modified Files -- src/test/regress/expected/explain.out | 3 +++ src/test/regress/sql/explain.sql | 5 + 2 files changed, 8 insertions(+)
Re: pgsql: Allow numeric scale to be negative or greater than precision.
On Tue, 27 Jul 2021 at 17:22, Tom Lane wrote: > > Simon Riggs writes: > > This is for migration? > > Yeah, compatibility with some other DBMSes that allow this. > > > Or does it mean very small values now occupy less space since we store > > fewer zeros? > > It won't affect space consumption at all, as NUMERIC has never stored > leading or trailing zeroes. (Modulo the fact that "zero" here means > a base-NDIGIT digit.) Thanks, just trying to understand what that was for. -- Simon Riggshttp://www.EnterpriseDB.com/
Re: pgsql: Re-enable TAP tests of pg_receivewal for ZLIB on Windows
On 7/21/21 9:08 PM, Andrew Dunstan wrote: > On 7/21/21 8:00 PM, Michael Paquier wrote: >> On Wed, Jul 21, 2021 at 10:05:19AM -0400, Andrew Dunstan wrote: >>> drongo, an MSVC animal running on the same machine, doesn't seem to have >>> an issue, nor jacana which runs msys1, so this seems possibly >>> msys2-specific. I'll investigate on a similar instance I have. >> How is doing bowerbird? I was waiting for it to send an update before >> doing anything but there is no report yet. Is it getting stuck? I >> would feel honestly less sad about those tests if this proves to >> require temporarily a $is_msys2 rather than a $windows_os. > > > Yeah, bowerbird got a SIGBREAK that caused the whole buildfarm run to > die, so it's even worse than fairywren. > > > Let's skip for $windows_os and do some more thorough investigation. > > I have got to the bottom of the issue on fairywren - it was caused by using a zlib I had build (and which is used on drongo) rather than the mingw64 zlib package. So I've switched that. While doing that I uncovered some more things that need to be fixed for portability both in TestLib and the pg_basebackup tests, Meanwhile I will now go and investigate what's happening with bowerbird. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
pgsql: Fix bugs in polymorphic-argument resolution for multiranges.
Fix bugs in polymorphic-argument resolution for multiranges. We failed to deal with an UNKNOWN-type input for anycompatiblemultirange; that should throw an error indicating that we don't know how to resolve the multirange type. We also failed to infer the type of an anycompatiblerange output from an anycompatiblemultirange input or vice versa. Per bug #17066 from Alexander Lakhin. Back-patch to v14 where multiranges were added. Discussion: https://postgr.es/m/[email protected] Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b7ea0e8c41f1e512923267a57cd08df63115b783 Modified Files -- src/backend/parser/parse_coerce.c | 316 - src/test/regress/expected/polymorphism.out | 68 ++- src/test/regress/expected/rangefuncs.out | 2 +- src/test/regress/sql/polymorphism.sql | 48 + 4 files changed, 293 insertions(+), 141 deletions(-)
pgsql: Fix bugs in polymorphic-argument resolution for multiranges.
Fix bugs in polymorphic-argument resolution for multiranges. We failed to deal with an UNKNOWN-type input for anycompatiblemultirange; that should throw an error indicating that we don't know how to resolve the multirange type. We also failed to infer the type of an anycompatiblerange output from an anycompatiblemultirange input or vice versa. Per bug #17066 from Alexander Lakhin. Back-patch to v14 where multiranges were added. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/336ea6e6ff1109e7b83370565e3cb211804fda0c Modified Files -- src/backend/parser/parse_coerce.c | 316 - src/test/regress/expected/polymorphism.out | 68 ++- src/test/regress/expected/rangefuncs.out | 2 +- src/test/regress/sql/polymorphism.sql | 48 + 4 files changed, 293 insertions(+), 141 deletions(-)
pgsql: Set pg_setting.pending_restart when pertinent config lines are r
Set pg_setting.pending_restart when pertinent config lines are removed This changes the behavior of examining the pg_file_settings view after changing a config option that requires restart. The user needs to know that any change of such options does not take effect until a restart, and this worked correctly if the line is edited without removing it. However, for the case where the line is removed altogether, the flag doesn't get set, because a flag was only set in set_config_option, but that's not called for lines removed. Repair. (Ref.: commits 62d16c7fc561 and a486e35706ea) Author: Álvaro Herrera Reviewed-by: Daniel Gustafsson Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/85ec6c32265013ad2de145c3684fb026e094f0cb Modified Files -- src/backend/utils/misc/guc-file.l | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Set pg_setting.pending_restart when pertinent config lines are r
Set pg_setting.pending_restart when pertinent config lines are removed This changes the behavior of examining the pg_file_settings view after changing a config option that requires restart. The user needs to know that any change of such options does not take effect until a restart, and this worked correctly if the line is edited without removing it. However, for the case where the line is removed altogether, the flag doesn't get set, because a flag was only set in set_config_option, but that's not called for lines removed. Repair. (Ref.: commits 62d16c7fc561 and a486e35706ea) Author: Álvaro Herrera Reviewed-by: Daniel Gustafsson Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/04fa0e11ac20cb3f26639bb95334b45fc81ebec5 Modified Files -- src/backend/utils/misc/guc-file.l | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Set pg_setting.pending_restart when pertinent config lines are r
Set pg_setting.pending_restart when pertinent config lines are removed This changes the behavior of examining the pg_file_settings view after changing a config option that requires restart. The user needs to know that any change of such options does not take effect until a restart, and this worked correctly if the line is edited without removing it. However, for the case where the line is removed altogether, the flag doesn't get set, because a flag was only set in set_config_option, but that's not called for lines removed. Repair. (Ref.: commits 62d16c7fc561 and a486e35706ea) Author: Álvaro Herrera Reviewed-by: Daniel Gustafsson Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b8f91d7f926368115c27b978c939174c96df1a5f Modified Files -- src/backend/utils/misc/guc-file.l | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Set pg_setting.pending_restart when pertinent config lines are r
Set pg_setting.pending_restart when pertinent config lines are removed This changes the behavior of examining the pg_file_settings view after changing a config option that requires restart. The user needs to know that any change of such options does not take effect until a restart, and this worked correctly if the line is edited without removing it. However, for the case where the line is removed altogether, the flag doesn't get set, because a flag was only set in set_config_option, but that's not called for lines removed. Repair. (Ref.: commits 62d16c7fc561 and a486e35706ea) Author: Álvaro Herrera Reviewed-by: Daniel Gustafsson Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6feb229f53f8de704ee2ff709d2c44e1c4d6be92 Modified Files -- src/backend/utils/misc/guc-file.l | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Set pg_setting.pending_restart when pertinent config lines are r
Set pg_setting.pending_restart when pertinent config lines are removed This changes the behavior of examining the pg_file_settings view after changing a config option that requires restart. The user needs to know that any change of such options does not take effect until a restart, and this worked correctly if the line is edited without removing it. However, for the case where the line is removed altogether, the flag doesn't get set, because a flag was only set in set_config_option, but that's not called for lines removed. Repair. (Ref.: commits 62d16c7fc561 and a486e35706ea) Author: Álvaro Herrera Reviewed-by: Daniel Gustafsson Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ddd1eac9936946a8ecdb97d1b25495f4781357f8 Modified Files -- src/backend/utils/misc/guc-file.l | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Set pg_setting.pending_restart when pertinent config lines are r
Set pg_setting.pending_restart when pertinent config lines are removed This changes the behavior of examining the pg_file_settings view after changing a config option that requires restart. The user needs to know that any change of such options does not take effect until a restart, and this worked correctly if the line is edited without removing it. However, for the case where the line is removed altogether, the flag doesn't get set, because a flag was only set in set_config_option, but that's not called for lines removed. Repair. (Ref.: commits 62d16c7fc561 and a486e35706ea) Author: Álvaro Herrera Reviewed-by: Daniel Gustafsson Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/93a0bf2390327a482ff37317f6e17547e735409e Modified Files -- src/backend/utils/misc/guc-file.l | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Set pg_setting.pending_restart when pertinent config lines are r
Set pg_setting.pending_restart when pertinent config lines are removed This changes the behavior of examining the pg_file_settings view after changing a config option that requires restart. The user needs to know that any change of such options does not take effect until a restart, and this worked correctly if the line is edited without removing it. However, for the case where the line is removed altogether, the flag doesn't get set, because a flag was only set in set_config_option, but that's not called for lines removed. Repair. (Ref.: commits 62d16c7fc561 and a486e35706ea) Author: Álvaro Herrera Reviewed-by: Daniel Gustafsson Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ad3b40eb26a30d376e8448eb1170421501f0fc6b Modified Files -- src/backend/utils/misc/guc-file.l | 2 ++ 1 file changed, 2 insertions(+)
Re: pgsql: Re-enable TAP tests of pg_receivewal for ZLIB on Windows
On Tue, Jul 27, 2021 at 02:24:12PM -0400, Andrew Dunstan wrote: > I have got to the bottom of the issue on fairywren - it was caused by > using a zlib I had build (and which is used on drongo) rather than the > mingw64 zlib package. So I've switched that. Thanks! > While doing that I uncovered some more things that need to be fixed for > portability both in TestLib and the pg_basebackup tests, What did you uncover here? -- Michael signature.asc Description: PGP signature
pgsql: Remove seemingly unneeded include directory in MSVC scripts
Remove seemingly unneeded include directory in MSVC scripts This appears to have been added way back in ee3b4188a but it's a little unclear why the change made in that commit is even needed given that 320c7eb8c, dated 18 months earlier, added code to copy fmgroids.h to src/include/utils. amcheck seems to get away without adding the additional include directory, so perhaps dblink can get away with it too. This builds ok in my VS2017 environment, but the buildfarm may serve as a reminder about why ee3b4188a was required. There's only one way to find out for sure. Discussion: https://postgr.es/m/CAApHDvpo6g5csCTjc_0C7DMvgFPomVb0Rh-AcW5afd=Ya=l...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4b763ff642e1a3608cbcaff062f6c2f465bfc6bd Modified Files -- src/tools/msvc/Mkvcbuild.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Add support for SET ACCESS METHOD in ALTER TABLE
Add support for SET ACCESS METHOD in ALTER TABLE The logic used to support a change of access method for a table is similar to changes for tablespace or relation persistence, requiring a table rewrite with an exclusive lock of the relation changed. Table rewrites done in ALTER TABLE already go through the table AM layer when scanning tuples from the old relation and inserting them into the new one, making this implementation straight-forward. Note that partitioned tables are not supported as these have no access methods defined. Author: Justin Pryzby, Jeff Davis Reviewed-by: Michael Paquier, Vignesh C Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b0483263dda0824cc49e3f8a022dab07e1cdf9a7 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 20 ++ src/backend/commands/cluster.c | 21 --- src/backend/commands/matview.c | 5 ++- src/backend/commands/tablecmds.c| 66 +++-- src/backend/parser/gram.y | 8 src/bin/psql/tab-complete.c | 11 +- src/include/commands/cluster.h | 4 +- src/include/commands/event_trigger.h| 1 + src/include/nodes/parsenodes.h | 1 + src/test/regress/expected/create_am.out | 34 + src/test/regress/sql/create_am.sql | 17 + 11 files changed, 173 insertions(+), 15 deletions(-)
pgsql: Clarify some comments making use of leetspeak term "up2date"
Clarify some comments making use of leetspeak term "up2date" Most of these are new, as of a8fd13c, and "up-to-date" is much easier to parse for the average reader. Author: Peter Smith Discussion: https://postgr.es/m/cahut+pthbhvgojs_r9lydf21j-wn8sxottwmqnp2ifxn6t2...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7b7fbe1e8bb4b2a244d1faa618789db411316e55 Modified Files -- src/backend/jit/llvm/llvmjit_expr.c | 2 +- src/backend/replication/logical/logical.c | 24 2 files changed, 13 insertions(+), 13 deletions(-)
pgsql: Doc: Clarify lock levels taken during ATTACH PARTITION
Doc: Clarify lock levels taken during ATTACH PARTITION It wasn't all that clear which lock levels, if any, would be held on the DEFAULT partition during an ATTACH PARTITION operation. Also, clarify which locks will be taken if the DEFAULT partition or the table being attached are themselves partitioned tables. Here I'm only backpatching to v12 as before then we obtained an ACCESS EXCLUSIVE lock on the partitioned table. It seems much less relevant to mention which locks are taken on other tables when the partitioned table itself is locked with an ACCESS EXCLUSIVE lock. Author: Matthias van de Meent, David Rowley Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnz7foww3qu-8iq8zchp3fiq6+...@mail.gmail.com Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8709228775b549a2388e6568f463a4115e5a4c10 Modified Files -- doc/src/sgml/ddl.sgml | 28 +--- doc/src/sgml/ref/alter_table.sgml | 13 +++-- 2 files changed, 36 insertions(+), 5 deletions(-)
pgsql: Doc: Clarify lock levels taken during ATTACH PARTITION
Doc: Clarify lock levels taken during ATTACH PARTITION It wasn't all that clear which lock levels, if any, would be held on the DEFAULT partition during an ATTACH PARTITION operation. Also, clarify which locks will be taken if the DEFAULT partition or the table being attached are themselves partitioned tables. Here I'm only backpatching to v12 as before then we obtained an ACCESS EXCLUSIVE lock on the partitioned table. It seems much less relevant to mention which locks are taken on other tables when the partitioned table itself is locked with an ACCESS EXCLUSIVE lock. Author: Matthias van de Meent, David Rowley Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnz7foww3qu-8iq8zchp3fiq6+...@mail.gmail.com Backpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5a8a9be08307a1c06fbed4510667de6b4f40fe56 Modified Files -- doc/src/sgml/ddl.sgml | 28 +--- doc/src/sgml/ref/alter_table.sgml | 13 +++-- 2 files changed, 36 insertions(+), 5 deletions(-)
pgsql: Doc: Clarify lock levels taken during ATTACH PARTITION
Doc: Clarify lock levels taken during ATTACH PARTITION It wasn't all that clear which lock levels, if any, would be held on the DEFAULT partition during an ATTACH PARTITION operation. Also, clarify which locks will be taken if the DEFAULT partition or the table being attached are themselves partitioned tables. Here I'm only backpatching to v12 as before then we obtained an ACCESS EXCLUSIVE lock on the partitioned table. It seems much less relevant to mention which locks are taken on other tables when the partitioned table itself is locked with an ACCESS EXCLUSIVE lock. Author: Matthias van de Meent, David Rowley Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnz7foww3qu-8iq8zchp3fiq6+...@mail.gmail.com Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aa1e9211ecf7ef410b4313f0e061de087aed0aa2 Modified Files -- doc/src/sgml/ddl.sgml | 28 +--- doc/src/sgml/ref/alter_table.sgml | 13 +++-- 2 files changed, 36 insertions(+), 5 deletions(-)
pgsql: Doc: Clarify lock levels taken during ATTACH PARTITION
Doc: Clarify lock levels taken during ATTACH PARTITION It wasn't all that clear which lock levels, if any, would be held on the DEFAULT partition during an ATTACH PARTITION operation. Also, clarify which locks will be taken if the DEFAULT partition or the table being attached are themselves partitioned tables. Here I'm only backpatching to v12 as before then we obtained an ACCESS EXCLUSIVE lock on the partitioned table. It seems much less relevant to mention which locks are taken on other tables when the partitioned table itself is locked with an ACCESS EXCLUSIVE lock. Author: Matthias van de Meent, David Rowley Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnz7foww3qu-8iq8zchp3fiq6+...@mail.gmail.com Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c590904d50cc93b12fc895041c34e1ea821e768c Modified Files -- doc/src/sgml/ddl.sgml | 28 +--- doc/src/sgml/ref/alter_table.sgml | 13 +++-- 2 files changed, 36 insertions(+), 5 deletions(-)
