Re: type in basebackup_incremental.c ?
>Sent: Thursday, April 11, 2024 12:15 >To: Daniel Westermann (DWE) >Cc: PostgreSQL Hackers >Subject: Re: type in basebackup_incremental.c ? > >> On 11 Apr 2024, at 11:49, Daniel Westermann (DWE) >> wrote: >> >> Hi, >> >> /* >> * we expect the find the last lines of the manifest, including the checksum, >> * in the last MIN_CHUNK bytes of the manifest. We trigger an incremental >> * parse step if we are about to overflow MAX_CHUNK bytes. >> */ >> >> Shouldn't this be: >> /* >> * we expect to find the last lines of the manifest,... >> */ >That sounds about right, and since it's a full sentence it should also start >with a capital 'W': "We expect to find the..". ... and a bit further down: * We don't really need this information, because we use WAL summaries to * figure what's changed. Should probably be: ...because we use WAL summaries to figure out ... Regards Daniel
type in basebackup_incremental.c ?
Hi, /* * we expect the find the last lines of the manifest, including the checksum, * in the last MIN_CHUNK bytes of the manifest. We trigger an incremental * parse step if we are about to overflow MAX_CHUNK bytes. */ Shouldn't this be: /* * we expect to find the last lines of the manifest,... */ Regards Daniel
Re: Incorrect cost for MergeAppend
Hi, >Since we have a minor coming up very soon, I think it's not a good idea >to backpatch right now. Maybe you can push to master now, and consider >whether to backpatch later. >The problem is -- if somebody has an application that gets good plans >with the current cost model, and you change the cost model and the plans >become worse, what do they do? If you change this in a major release, >this is not an issue because they must test their queries before >upgrading and if they fail to realize a problem exists then it's their >fault. If you change it in a minor release, then those people will be >very upset that things were changed suddenly, and they may get wary of >future minor upgrades, which we don't want. I agree with this, especially as we tell our customers that such changes do not happen from one minor release to another. Regards Daniel
Compiler warning on Debian 12, PostgreSQL 16 Beta3
Hi, I've just noticed this warning when building on Debian 12: In file included from /usr/lib/llvm-14/include/llvm/Analysis/ModuleSummaryAnalysis.h:17, from llvmjit_inline.cpp:51: /usr/lib/llvm-14/include/llvm/IR/ModuleSummaryIndex.h: In constructor ‘llvm::ModuleSummaryIndex::ModuleSummaryIndex(bool, bool)’: /usr/lib/llvm-14/include/llvm/IR/ModuleSummaryIndex.h:1175:73: warning: member ‘llvm::ModuleSummaryIndex::Alloc’ is used uninitialized [-Wuninitialized] 1175 | : HaveGVs(HaveGVs), EnableSplitLTOUnit(EnableSplitLTOUnit), Saver(Alloc), | cat /etc/debian_version 12.1 Regards Daniel
Typo in src/backend/access/nbtree/README?
Hi, I am not a native English speaker, but shouldn't there be a "to" before "detect"? These two additions make it possible detect a concurrent page split Regards Daniel
pg_upgrade, tables_with_oids.txt -> tables_with_oids.sql?
Hi, as I've just upgraded an instance which contained tables "WITH OIDS" I wonder if it would make sense if pg_upgrade directly creates a script to fix those. I know it is easy to that with e.g. sed over tables_with_oids.txt but it would be more convenient to have the script generated directly. Thoughts? Regards Daniel
Re: Changing "Hot Standby" to "hot standby"
>Looks the same as v5 for me, that applies the same consistency rules >everywhere in the docs. So applied this one. Thank you, Michael
Re: Changing "Hot Standby" to "hot standby"
>>>Hmm. Outside the title that had better use upper-case characters for >>>the first letter of each word, I can see references to the pattern you >>>are trying to eliminate in amcheck.sgml (1), config.sgml (3), >>>protocol.sgml (3) and mvcc.sgml (1). Shouldn't you refresh these as >>>well if the point is to make the full set of docs consistent? >>>As of the full tree, I can see that: >>> >>$ git grep "hot standby" | wc -l >>259 >>$ git grep "Hot Standby" | wc -l >>73 >>>So there is a trend for one of the two. >>Thanks for looking at it. Yes, I am aware there are other places which would >>need to be changed and I think I mentioned that in an >>earlier Email. Are >>you suggesting to change all at once? I wanted to start with the >>documentation and then continue with the other >>places. >Attached a new version which also modifies amcheck.sgml, config.sgml, >protocol.sgml, and mvcc.sgml accordingly. Regards Daniel From: Daniel Westermann (DWE) Sent: Wednesday, March 9, 2022 15:15 To: Michael Paquier Cc: Robert Treat ; Kyotaro Horiguchi ; aleksan...@timescale.com ; pgsql-hackers@lists.postgresql.org Subject: Re: Changing "Hot Standby" to "hot standby" >>Hmm. Outside the title that had better use upper-case characters for >>the first letter of each word, I can see references to the pattern you >>are trying to eliminate in amcheck.sgml (1), config.sgml (3), >>protocol.sgml (3) and mvcc.sgml (1). Shouldn't you refresh these as >>well if the point is to make the full set of docs consistent? >>As of the full tree, I can see that: >> >>$ git grep "hot standby" | wc -l >>259 >>$ git grep "Hot Standby" | wc -l >>73 >>So there is a trend for one of the two. >>Thanks for looking at it. Yes, I am aware there are other places which would >>need to be changed and I think I mentioned that in an >>earlier Email. Are >>you suggesting to change all at once? I wanted to start with the >>documentation and then continue with the other >>places. >Attached a new version which also modifies amcheck.sgml, config.sgml, >protocol.sgml, and mvcc.sgml accordingly. Sending this again as my last two mails did not seem to reach the archives or the commitfest. Or do they need moderation somehow? Regards Danieldiff --git a/doc/src/sgml/amcheck.sgml b/doc/src/sgml/amcheck.sgml index 11d1eb5af2..5d61a33936 100644 --- a/doc/src/sgml/amcheck.sgml +++ b/doc/src/sgml/amcheck.sgml @@ -174,7 +174,7 @@ ORDER BY c.relpages DESC LIMIT 10; hypothetically, undiscovered bugs in the underlying B-Tree index access method code. Note that bt_index_parent_check cannot be used when - Hot Standby mode is enabled (i.e., on read-only physical + hot standby mode is enabled (i.e., on read-only physical replicas), unlike bt_index_check. diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 7ed8c82a9d..e2db2a789f 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -4550,7 +4550,7 @@ ANY num_sync ( . @@ -4582,7 +4582,7 @@ ANY num_sync ( . @@ -10887,7 +10887,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir' Enables logging of recovery-related debugging output that otherwise would not be logged. This parameter allows the user to override the normal setting of , but only for -specific messages. This is intended for use in debugging Hot Standby. +specific messages. This is intended for use in debugging hot standby. Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, and LOG. The default, LOG, does not affect diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index b5b6042104..81fa26f985 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -548,8 +548,8 @@ protocol to make nodes agree on a serializable transactional order. rollforward will take considerably longer, so that technique only offers a solution for disaster recovery, not high availability. A standby server can also be used for read-only queries, in which case - it is called a Hot Standby server. See for - more information. + it is called a hot standby server. See +for more information. @@ -1032,7 +1032,7 @@ primary_slot_name = 'node_a_slot' -Hot Standby feedback propagates upstream, whatever the cascaded arrangement. +Hot standby feedback propagates upstream, whatever the cascaded arrangement. @@ -1499,16 +1499,16 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' Hot Standby - Hot Standby + hot standby -Hot Sta
Re: Changing "Hot Standby" to "hot standby"
>>Hmm. Outside the title that had better use upper-case characters for >>the first letter of each word, I can see references to the pattern you >>are trying to eliminate in amcheck.sgml (1), config.sgml (3), >>protocol.sgml (3) and mvcc.sgml (1). Shouldn't you refresh these as >>well if the point is to make the full set of docs consistent? >>As of the full tree, I can see that: >> >>$ git grep "hot standby" | wc -l >>259 >>$ git grep "Hot Standby" | wc -l >>73 >>So there is a trend for one of the two. >Thanks for looking at it. Yes, I am aware there are other places which would >need to be changed and I think I mentioned that in an >earlier Email. Are you >suggesting to change all at once? I wanted to start with the documentation and >then continue with the other >places. Attached a new version which also modifies amcheck.sgml, config.sgml, protocol.sgml, and mvcc.sgml accordingly. Regards Danieldiff --git a/doc/src/sgml/amcheck.sgml b/doc/src/sgml/amcheck.sgml index 11d1eb5af2..5d61a33936 100644 --- a/doc/src/sgml/amcheck.sgml +++ b/doc/src/sgml/amcheck.sgml @@ -174,7 +174,7 @@ ORDER BY c.relpages DESC LIMIT 10; hypothetically, undiscovered bugs in the underlying B-Tree index access method code. Note that bt_index_parent_check cannot be used when - Hot Standby mode is enabled (i.e., on read-only physical + hot standby mode is enabled (i.e., on read-only physical replicas), unlike bt_index_check. diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 7ed8c82a9d..e2db2a789f 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -4550,7 +4550,7 @@ ANY num_sync ( . @@ -4582,7 +4582,7 @@ ANY num_sync ( . @@ -10887,7 +10887,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir' Enables logging of recovery-related debugging output that otherwise would not be logged. This parameter allows the user to override the normal setting of , but only for -specific messages. This is intended for use in debugging Hot Standby. +specific messages. This is intended for use in debugging hot standby. Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, and LOG. The default, LOG, does not affect diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index b5b6042104..81fa26f985 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -548,8 +548,8 @@ protocol to make nodes agree on a serializable transactional order. rollforward will take considerably longer, so that technique only offers a solution for disaster recovery, not high availability. A standby server can also be used for read-only queries, in which case - it is called a Hot Standby server. See for - more information. + it is called a hot standby server. See +for more information. @@ -1032,7 +1032,7 @@ primary_slot_name = 'node_a_slot' -Hot Standby feedback propagates upstream, whatever the cascaded arrangement. +Hot standby feedback propagates upstream, whatever the cascaded arrangement. @@ -1499,16 +1499,16 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' Hot Standby - Hot Standby + hot standby -Hot Standby is the term used to describe the ability to connect to +Hot standby is the term used to describe the ability to connect to the server and run read-only queries while the server is in archive recovery or standby mode. This is useful both for replication purposes and for restoring a backup to a desired state with great precision. -The term Hot Standby also refers to the ability of the server to move +The term hot standby also refers to the ability of the server to move from recovery through to normal operation while users continue running queries and/or keep their connections open. @@ -1623,7 +1623,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' being executed during recovery. This restriction applies even to temporary tables, because table rows cannot be read or written without assigning a transaction ID, which is currently not possible in a - Hot Standby environment. + hot standby environment. @@ -1703,7 +1703,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' In normal operation, read-only transactions are allowed to use LISTEN and NOTIFY, -so Hot Standby sessions operate under slightly tighter +so hot standby sessions operate under slightly tighter restrictions than ordinary read-only sessions. It is possible that some of these restrictions might be loosened in a future release. @@ -1746,7 +1746,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' -There are also additional types of conflict that can occur with Hot Standby. +There are
Re: Changing "Hot Standby" to "hot standby"
Hi Michael, >On Wed, Mar 09, 2022 at 07:45:32AM +0000, Daniel Westermann (DWE) wrote: >> Thanks for having a look. Done that way. >Hmm. Outside the title that had better use upper-case characters for >the first letter of each word, I can see references to the pattern you >are trying to eliminate in amcheck.sgml (1), config.sgml (3), >protocol.sgml (3) and mvcc.sgml (1). Shouldn't you refresh these as >well if the point is to make the full set of docs consistent? >As of the full tree, I can see that: > >$ git grep "hot standby" | wc -l >259 >$ git grep "Hot Standby" | wc -l >73 >So there is a trend for one of the two. Thanks for looking at it. Yes, I am aware there are other places which would need to be changed and I think I mentioned that in an earlier Email. Are you suggesting to change all at once? I wanted to start with the documentation and then continue with the other places. Regards Daniel
Re: Changing "Hot Standby" to "hot standby"
>I think one more small change... > A standby server can also be used for read-only queries, in which case >- it is called a Hot Standby server. See for >+ it is called a hot standby server. See for > more information. > A standby server can also be used for read-only queries, in which case >- it is called a Hot Standby server. See for >+ it is called a hot standby server. See > for > more information. Thanks for having a look. Done that way. Regards Daniel diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index b5b6042104..81fa26f985 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -548,8 +548,8 @@ protocol to make nodes agree on a serializable transactional order. rollforward will take considerably longer, so that technique only offers a solution for disaster recovery, not high availability. A standby server can also be used for read-only queries, in which case - it is called a Hot Standby server. See for - more information. + it is called a hot standby server. See +for more information. @@ -1032,7 +1032,7 @@ primary_slot_name = 'node_a_slot' -Hot Standby feedback propagates upstream, whatever the cascaded arrangement. +Hot standby feedback propagates upstream, whatever the cascaded arrangement. @@ -1499,16 +1499,16 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' Hot Standby - Hot Standby + hot standby -Hot Standby is the term used to describe the ability to connect to +Hot standby is the term used to describe the ability to connect to the server and run read-only queries while the server is in archive recovery or standby mode. This is useful both for replication purposes and for restoring a backup to a desired state with great precision. -The term Hot Standby also refers to the ability of the server to move +The term hot standby also refers to the ability of the server to move from recovery through to normal operation while users continue running queries and/or keep their connections open. @@ -1623,7 +1623,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' being executed during recovery. This restriction applies even to temporary tables, because table rows cannot be read or written without assigning a transaction ID, which is currently not possible in a - Hot Standby environment. + hot standby environment. @@ -1703,7 +1703,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' In normal operation, read-only transactions are allowed to use LISTEN and NOTIFY, -so Hot Standby sessions operate under slightly tighter +so hot standby sessions operate under slightly tighter restrictions than ordinary read-only sessions. It is possible that some of these restrictions might be loosened in a future release. @@ -1746,7 +1746,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' -There are also additional types of conflict that can occur with Hot Standby. +There are also additional types of conflict that can occur with hot standby. These conflicts are hard conflicts in the sense that queries might need to be canceled and, in some cases, sessions disconnected to resolve them. The user is provided with several ways to handle these @@ -1947,8 +1947,8 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' If hot_standby is on in postgresql.conf (the default value) and there is a standby.signalstandby.signalfor hot standby -file present, the server will run in Hot Standby mode. -However, it may take some time for Hot Standby connections to be allowed, +file present, the server will run in hot standby mode. +However, it may take some time for hot standby connections to be allowed, because the server will not accept connections until it has completed sufficient recovery to provide a consistent state against which queries can run. During this period, @@ -2282,7 +2282,7 @@ HINT: You can then restart the server after making the necessary configuration Caveats -There are several limitations of Hot Standby. +There are several limitations of hot standby. These can and probably will be fixed in future releases: @@ -2299,7 +2299,7 @@ HINT: You can then restart the server after making the necessary configuration Valid starting points for standby queries are generated at each checkpoint on the primary. If the standby is shut down while the primary - is in a shutdown state, it might not be possible to re-enter Hot Standby + is in a shutdown state, it might not be possible to re-enter hot standby until the primary is started up, so that it generates further starting points in the WAL logs. This situation isn't a problem in the most
Re: Changing "Hot Standby" to "hot standby"
>>> Thanks for having a look. Are you suggesting to change it like this? >>> -Hot Standby is the term used to describe the ability to connect to >>> +Hot standby is the term used to describe the ability to connect to >>Yes. Isn't it the right form of a sentence? I've created and entry in the Commitfest 2022-07 for this. Regards Daniel
Re: Changing "Hot Standby" to "hot standby"
>> Thanks for having a look. Are you suggesting to change it like this? >> - Hot Standby is the term used to describe the ability to connect to >> + Hot standby is the term used to describe the ability to connect to >Yes. Isn't it the right form of a sentence? Done like that. Regards Danieldiff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index b5b6042104..ea10fe2be8 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -548,7 +548,7 @@ protocol to make nodes agree on a serializable transactional order. rollforward will take considerably longer, so that technique only offers a solution for disaster recovery, not high availability. A standby server can also be used for read-only queries, in which case - it is called a Hot Standby server. See for + it is called a hot standby server. See for more information. @@ -1032,7 +1032,7 @@ primary_slot_name = 'node_a_slot' -Hot Standby feedback propagates upstream, whatever the cascaded arrangement. +Hot standby feedback propagates upstream, whatever the cascaded arrangement. @@ -1499,16 +1499,16 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' Hot Standby - Hot Standby + hot standby -Hot Standby is the term used to describe the ability to connect to +Hot standby is the term used to describe the ability to connect to the server and run read-only queries while the server is in archive recovery or standby mode. This is useful both for replication purposes and for restoring a backup to a desired state with great precision. -The term Hot Standby also refers to the ability of the server to move +The term hot standby also refers to the ability of the server to move from recovery through to normal operation while users continue running queries and/or keep their connections open. @@ -1623,7 +1623,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' being executed during recovery. This restriction applies even to temporary tables, because table rows cannot be read or written without assigning a transaction ID, which is currently not possible in a - Hot Standby environment. + hot standby environment. @@ -1703,7 +1703,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' In normal operation, read-only transactions are allowed to use LISTEN and NOTIFY, -so Hot Standby sessions operate under slightly tighter +so hot standby sessions operate under slightly tighter restrictions than ordinary read-only sessions. It is possible that some of these restrictions might be loosened in a future release. @@ -1746,7 +1746,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' -There are also additional types of conflict that can occur with Hot Standby. +There are also additional types of conflict that can occur with hot standby. These conflicts are hard conflicts in the sense that queries might need to be canceled and, in some cases, sessions disconnected to resolve them. The user is provided with several ways to handle these @@ -1947,8 +1947,8 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' If hot_standby is on in postgresql.conf (the default value) and there is a standby.signalstandby.signalfor hot standby -file present, the server will run in Hot Standby mode. -However, it may take some time for Hot Standby connections to be allowed, +file present, the server will run in hot standby mode. +However, it may take some time for hot standby connections to be allowed, because the server will not accept connections until it has completed sufficient recovery to provide a consistent state against which queries can run. During this period, @@ -2282,7 +2282,7 @@ HINT: You can then restart the server after making the necessary configuration Caveats -There are several limitations of Hot Standby. +There are several limitations of hot standby. These can and probably will be fixed in future releases: @@ -2299,7 +2299,7 @@ HINT: You can then restart the server after making the necessary configuration Valid starting points for standby queries are generated at each checkpoint on the primary. If the standby is shut down while the primary - is in a shutdown state, it might not be possible to re-enter Hot Standby + is in a shutdown state, it might not be possible to re-enter hot standby until the primary is started up, so that it generates further starting points in the WAL logs. This situation isn't a problem in the most common situations where it might happen. Generally, if the primary is
Re: Changing "Hot Standby" to "hot standby"
Hi Kyotaro, >> >>- Hot Standby is the term used to describe the ability to connect to >>+ hot standby is the term used to describe the ability to connect to >They look like decapitalizing the first word in a sentsnce. Thanks for having a look. Are you suggesting to change it like this? -Hot Standby is the term used to describe the ability to connect to +Hot standby is the term used to describe the ability to connect to Regards Daniel
Re: Changing "Hot Standby" to "hot standby"
Hi Aleksander, > Pretty sure that for titles we should keep English capitalization rules. Done like that. Thanks for taking a look. Regards Danieldiff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index b5b6042104..08eb1ad946 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -548,7 +548,7 @@ protocol to make nodes agree on a serializable transactional order. rollforward will take considerably longer, so that technique only offers a solution for disaster recovery, not high availability. A standby server can also be used for read-only queries, in which case - it is called a Hot Standby server. See for + it is called a hot standby server. See for more information. @@ -1032,7 +1032,7 @@ primary_slot_name = 'node_a_slot' -Hot Standby feedback propagates upstream, whatever the cascaded arrangement. +hot standby feedback propagates upstream, whatever the cascaded arrangement. @@ -1499,16 +1499,16 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' Hot Standby - Hot Standby + hot standby -Hot Standby is the term used to describe the ability to connect to +hot standby is the term used to describe the ability to connect to the server and run read-only queries while the server is in archive recovery or standby mode. This is useful both for replication purposes and for restoring a backup to a desired state with great precision. -The term Hot Standby also refers to the ability of the server to move +The term hot standby also refers to the ability of the server to move from recovery through to normal operation while users continue running queries and/or keep their connections open. @@ -1623,7 +1623,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' being executed during recovery. This restriction applies even to temporary tables, because table rows cannot be read or written without assigning a transaction ID, which is currently not possible in a - Hot Standby environment. + hot standby environment. @@ -1703,7 +1703,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' In normal operation, read-only transactions are allowed to use LISTEN and NOTIFY, -so Hot Standby sessions operate under slightly tighter +so hot standby sessions operate under slightly tighter restrictions than ordinary read-only sessions. It is possible that some of these restrictions might be loosened in a future release. @@ -1746,7 +1746,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' -There are also additional types of conflict that can occur with Hot Standby. +There are also additional types of conflict that can occur with hot standby. These conflicts are hard conflicts in the sense that queries might need to be canceled and, in some cases, sessions disconnected to resolve them. The user is provided with several ways to handle these @@ -1947,8 +1947,8 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' If hot_standby is on in postgresql.conf (the default value) and there is a standby.signalstandby.signalfor hot standby -file present, the server will run in Hot Standby mode. -However, it may take some time for Hot Standby connections to be allowed, +file present, the server will run in hot standby mode. +However, it may take some time for hot standby connections to be allowed, because the server will not accept connections until it has completed sufficient recovery to provide a consistent state against which queries can run. During this period, @@ -2282,7 +2282,7 @@ HINT: You can then restart the server after making the necessary configuration Caveats -There are several limitations of Hot Standby. +There are several limitations of hot standby. These can and probably will be fixed in future releases: @@ -2299,7 +2299,7 @@ HINT: You can then restart the server after making the necessary configuration Valid starting points for standby queries are generated at each checkpoint on the primary. If the standby is shut down while the primary - is in a shutdown state, it might not be possible to re-enter Hot Standby + is in a shutdown state, it might not be possible to re-enter hot standby until the primary is started up, so that it generates further starting points in the WAL logs. This situation isn't a problem in the most common situations where it might happen. Generally, if the primary is
Changing "Hot Standby" to "hot standby"
Hi, with reference to the discussion in docs: https://www.postgresql.org/message-id/flat/2221339.1645896597%40sss.pgh.pa.us#5a346c15ec2edbe8fcc93a1ffc2a7c7d Here is a patch that changes "Hot Standby" to "hot standby" in high-availability.sgml, so we have a consistent wording. Thoughts? There are other places where hot standby is capitalized, but I guess we should start here. Regards Danieldiff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index b5b6042104..ec144489e5 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -548,7 +548,7 @@ protocol to make nodes agree on a serializable transactional order. rollforward will take considerably longer, so that technique only offers a solution for disaster recovery, not high availability. A standby server can also be used for read-only queries, in which case - it is called a Hot Standby server. See for + it is called a hot standby server. See for more information. @@ -1032,7 +1032,7 @@ primary_slot_name = 'node_a_slot' -Hot Standby feedback propagates upstream, whatever the cascaded arrangement. +hot standby feedback propagates upstream, whatever the cascaded arrangement. @@ -1496,19 +1496,19 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' - Hot Standby + hot standby - Hot Standby + hot standby -Hot Standby is the term used to describe the ability to connect to +hot standby is the term used to describe the ability to connect to the server and run read-only queries while the server is in archive recovery or standby mode. This is useful both for replication purposes and for restoring a backup to a desired state with great precision. -The term Hot Standby also refers to the ability of the server to move +The term hot standby also refers to the ability of the server to move from recovery through to normal operation while users continue running queries and/or keep their connections open. @@ -1623,7 +1623,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' being executed during recovery. This restriction applies even to temporary tables, because table rows cannot be read or written without assigning a transaction ID, which is currently not possible in a - Hot Standby environment. + hot standby environment. @@ -1703,7 +1703,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' In normal operation, read-only transactions are allowed to use LISTEN and NOTIFY, -so Hot Standby sessions operate under slightly tighter +so hot standby sessions operate under slightly tighter restrictions than ordinary read-only sessions. It is possible that some of these restrictions might be loosened in a future release. @@ -1746,7 +1746,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' -There are also additional types of conflict that can occur with Hot Standby. +There are also additional types of conflict that can occur with hot standby. These conflicts are hard conflicts in the sense that queries might need to be canceled and, in some cases, sessions disconnected to resolve them. The user is provided with several ways to handle these @@ -1947,8 +1947,8 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' If hot_standby is on in postgresql.conf (the default value) and there is a standby.signalstandby.signalfor hot standby -file present, the server will run in Hot Standby mode. -However, it may take some time for Hot Standby connections to be allowed, +file present, the server will run in hot standby mode. +However, it may take some time for hot standby connections to be allowed, because the server will not accept connections until it has completed sufficient recovery to provide a consistent state against which queries can run. During this period, @@ -2252,7 +2252,7 @@ HINT: You can then restart the server after making the necessary configuration - Hot Standby Parameter Reference + hot standby Parameter Reference Various parameters have been mentioned above in @@ -2282,7 +2282,7 @@ HINT: You can then restart the server after making the necessary configuration Caveats -There are several limitations of Hot Standby. +There are several limitations of hot standby. These can and probably will be fixed in future releases: @@ -2299,7 +2299,7 @@ HINT: You can then restart the server after making the necessary configuration Valid starting points for standby queries are generated at each checkpoint on the primary. If the standby is shut down while the primary - is in a shutdown state, it might not be possible to re-enter Hot Standby + is in a shutdown state, it might not be possible to re-enter hot standby
Re: faulty link
>The provided link > https://www.postgresql.org/docs/release/ >leads to > https://www.postgresql.org/docs/release/14.2/ >which gives 'Not Found' for me (Netherlands) Works fine for me in Germany Regards Daniel
Are we missing a dot in initdb's output?
Hi, this is more a cosmetic concern, but anyway: running initdb gives this output: ... creating configuration files ... ok running bootstrap script ... ok performing post-bootstrap initialization ... ok syncing data to disk ... ok initdb: warning: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb. ... Shouldn't there be a "." after "authentication for local connections"? Probably it should be like this: initdb: warning: Enabling "trust" authentication for local connections. initdb's output a few lines earlier gives this, which all close with a "dot" and start with upper case: "The database cluster will be initialized with locale "en_US.UTF-8". The default database encoding has accordingly been set to "UTF8". The default text search configuration will be set to "english". Data page checksums are disabled." Regards Daniel
Re: Should AT TIME ZONE be volatile?
>Laurenz Albe writes: >> On Thu, 2021-11-11 at 09:52 -0500, Tom Lane wrote: >>> Yup. If we had reliable ways to detect changes in this sort of >>> environment-supplied data, maybe we could do something about it >>> (a la the work that's been happening on attaching collation versions >>> to indexes). But personally I can't summon the motivation to work >>> on that, when ICU is the *only* such infrastructure that offers >>> readily program-readable versioning. >> Nobody will want to hear that, but the only really good solution would >> be for PostgreSQL to have its own built-in collations. >And our own tzdb too? Maybe an outfit like Oracle has the resources >and will to maintain their own copies of such data, but I can't see >us wanting to do it. >tzdb has an additional problem, which is that not updating is not an >option: if you're affected by a DST law change, you want that update, >and you frequently need it yesterday. We're definitely not set up >to handle that sort of update process, which is why we recommend >--with-system-tzdata. Where in the docs is this recommended? The only place I can find it is here: https://www.postgresql.org/docs/current/install-procedure.html Regards Daniel
Re: Tab completion for "create unlogged" a bit too lax?
>On Tue, Aug 24, 2021 at 11:32:14AM +0000, Daniel Westermann (DWE) wrote: >> tab completion for "create unlogged" gives this: >> >> postgres=# create unlogged >> MATERIALIZED VIEW TABLE >> >> Given that a materialized table can not be unlogged: >> >> postgres=# create unlogged materialized view mv1 as select 1; >> ERROR: materialized views cannot be unlogged >> >> Should this really show up there? >It seems to be deliberate: >commit 3223b25ff737c2bf4a642c0deb7be2b30bfecc6e >Author: Tom Lane >Date: Mon May 6 11:57:05 2013 -0400 > Disallow unlogged materialized views. >... > I left the grammar and tab-completion support for CREATE UNLOGGED > MATERIALIZED VIEW in place, since it's harmless and allows delivering a > more specific error message about the unsupported feature. Hm, I think tab completion should only give choices for operations that are supposed to work. Anyway, thanks for pointing me to the commit, that makes it more clear why it is that way. Regards Daniel
Tab completion for "create unlogged" a bit too lax?
Hi, tab completion for "create unlogged" gives this: postgres=# create unlogged MATERIALIZED VIEW TABLE Given that a materialized table can not be unlogged: postgres=# create unlogged materialized view mv1 as select 1; ERROR: materialized views cannot be unlogged Should this really show up there? Regards Daniel
Re: Small typo in variable.c
>On Tue, Jul 27, 2021 at 10:04:36AM +0000, Daniel Westermann (DWE) wrote: >> there is a typo in variable.c. >> Attached a small fix for this. >"iff" stands for "if and only if". Ah, good to know. Thx Regards Daniel
Small typo in variable.c
Hi, there is a typo in variable.c. Attached a small fix for this. Regards Danieldiff --git a/src/bin/psql/variables.c b/src/bin/psql/variables.c index 92a34f870f..538b83ddd9 100644 --- a/src/bin/psql/variables.c +++ b/src/bin/psql/variables.c @@ -361,7 +361,7 @@ SetVariableHooks(VariableSpace space, const char *name, } /* - * Return true iff the named variable has substitute and/or assign hook + * Return true if the named variable has substitute and/or assign hook * functions. */ bool
Re: check_function_bodies: At least the description seems wrong, since we have prodedures
>> It's possible the parameter name also appears in documentation for
>> out-of-tree PLs, as each PL's validator function determines what
>> "check_function_bodies" really means in that setting.
>That parameter is also set explicitly in pg_dump output, so we
>can't rename it without breaking existing dump files.
>Admittedly, guc.c does have provisions for substituting new names
>if we rename some parameter. But I'm not in a hurry to create
>more instances of that behavior; the potential for confusion
>seems to outweigh any benefit.
>+1 for updating the description though. We could s/function/routine/
>where space is tight.
Thanks for your inputs. Attached a proposal which updates the description.
Regards
Danieldiff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index ca378bd6af..d0a51b507d 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -1759,7 +1759,7 @@ static struct config_bool ConfigureNamesBool[] =
},
{
{"check_function_bodies", PGC_USERSET, CLIENT_CONN_STATEMENT,
- gettext_noop("Check function bodies during CREATE FUNCTION."),
+ gettext_noop("Check routine bodies during CREATE FUNCTION and CREATE PROCEDURE."),
NULL
},
_function_bodies,
check_function_bodies: At least the description seems wrong, since we have prodedures
Hi, check_function_bodies has this description: postgres=# select short_desc from pg_settings where name = 'check_function_bodies'; short_desc --- Check function bodies during CREATE FUNCTION. (1 row) This is not the whole truth since we have procedures, as this affects CREATE PROCEDURE as well: postgres=# create procedure p1 ( a int ) as $$ beginn null; end $$ language plpgsql; ERROR: syntax error at or near "beginn" LINE 1: create procedure p1 ( a int ) as $$ beginn null; end $$ lang... ^ postgres=# set check_function_bodies = false; SET postgres=# create procedure p1 ( a int ) as $$ beginn null; end $$ language plpgsql; CREATE PROCEDURE postgres=# At least the description should mention procedures. Even the parameter name seems not to be correct anymore. Thoughts? Regards Daniel
Another small guc.c fix
Hi,
all "short_desc" end with a dot, except these:
- Prefetch referenced blocks during recovery
- Prefetch blocks that have full page images in the WAL
Attached patch adds a dot to these as well.
Regards
Danieldiff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 46f1d6406f..6b126740df 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -1298,7 +1298,7 @@ static struct config_bool ConfigureNamesBool[] =
},
{
{"recovery_prefetch", PGC_SIGHUP, WAL_SETTINGS,
- gettext_noop("Prefetch referenced blocks during recovery"),
+ gettext_noop("Prefetch referenced blocks during recovery."),
gettext_noop("Read ahead of the current replay position to find uncached blocks.")
},
_prefetch,
@@ -1307,7 +1307,7 @@ static struct config_bool ConfigureNamesBool[] =
},
{
{"recovery_prefetch_fpw", PGC_SIGHUP, WAL_SETTINGS,
- gettext_noop("Prefetch blocks that have full page images in the WAL"),
+ gettext_noop("Prefetch blocks that have full page images in the WAL."),
gettext_noop("On some systems, there is no benefit to prefetching pages that will be "
"entirely overwritten, but if the logical page size of the filesystem is "
"larger than PostgreSQL's, this can be beneficial. This option has no "
Small typo in guc.c
Hi,
there is a small typo in guc.c. Attached patch fixes this.
Regards
Danieldiff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 090abdad8b..46f1d6406f 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -1320,7 +1320,7 @@ static struct config_bool ConfigureNamesBool[] =
{
{"wal_log_hints", PGC_POSTMASTER, WAL_SETTINGS,
- gettext_noop("Writes full pages to WAL when first modified after a checkpoint, even for a non-critical modifications."),
+ gettext_noop("Writes full pages to WAL when first modified after a checkpoint, even for a non-critical modification."),
NULL
},
_log_hints,
Re: src/tutorial/funcs.source: Wrong comment?
"Daniel Westermann (DWE)" writes: >> in "src/tutorial/funcs.source" there is this block: >> ... >> Actually it does work and I do not see a reason why this still should be >> commented. Thoughts? >Agreed and done. Thanks, Tom
src/tutorial/funcs.source: Wrong comment?
Hi, in "src/tutorial/funcs.source" there is this block: - -- Creating SQL Functions with multiple SQL statements -- you can also create functions that do more than just a SELECT. -- -- 14MAR99 Clark Evans: Does not quite work, commented out for now. -- - -- you may have noticed that Andy has a negative salary. We'll create a -- function that removes employees with negative salaries. -- -- SELECT * FROM EMP; -- -- CREATE FUNCTION clean_EMP () RETURNS integer --AS 'DELETE FROM EMP WHERE EMP.salary <= 0; --SELECT 1 AS ignore_this' --LANGUAGE SQL; -- -- SELECT clean_EMP(); -- -- SELECT * FROM EMP; Actually it does work and I do not see a reason why this still should be commented. Thoughts? Regards Daniel
Re: Parallel copy
On 27/10/2020 15:36, vignesh C wrote: >> Attached v9 patches have the fixes for the above comments. >I did some testing: I did some testing as well and have a cosmetic remark: postgres=# copy t1 from '/var/tmp/aa.txt' with (parallel 10); ERROR: value 10 out of bounds for option "parallel" DETAIL: Valid values are between "1" and "1024". postgres=# copy t1 from '/var/tmp/aa.txt' with (parallel 1000); ERROR: parallel requires an integer value postgres=# Wouldn't it make more sense to only have one error message? The first one seems to be the better message. Regards Daniel
Re: Wrong example in the bloom documentation
>I figured it out --- you have to use the larger generate_series value to >get the parallel output. I have adjusted all the docs back to 9.6 to >show accurate output for that version, and simplified the query >ordering --- patch to master attached. The other releases are similar. >Daniel, please let me know if I have left out any details. Thanks for your support on this. Looks good to me. Regards Daniel
Re: Wrong example in the bloom documentation
On Fri, Oct 9, 2020 at 11:08:32AM -0400, Bruce Momjian wrote: > On Fri, Oct 9, 2020 at 05:44:57AM +0000, Daniel Westermann (DWE) wrote: > > Hi Bruce, Tom, > > > > On Thu, Oct 8, 2020 at 03:43:32PM -0400, Tom Lane wrote: > > >> "Daniel Westermann (DWE)" writes: > > >> >> I was hoping someone more experienced with this would comment, but > > >> >> seeing none, I will apply it in a day or two to all supported > > >> >> versions? > > >> >> Have you tested this output back to 9.5? > > >> > > >> > I hoped that as well. No, I tested down to 9.6 because the change > > >> > happened in 10. > > >> > > >> The patch assumes that parallel query is enabled, which is not true by > > >> default before v10, so it should certainly not be applied before v10 > > >> (at least not without significant revisions). > >> > >> Yes, the behavior change was in 10. Before 10 the example is fine, I would > >> not apply that to any prior version, otherwise the whole example needs to > >> be rewritten. >> >> Agreed. >This is not applying to PG 12 or earlier because the patch mentions JIT, >which was only mentioned in the PG bloom docs in PG 13+. Does that mean we need separate patches for each release starting with 10? As I am not frequently writing patches, I would need some help here. Regards Daniel
Re: Wrong example in the bloom documentation
Hi Bruce, Tom, On Thu, Oct 8, 2020 at 03:43:32PM -0400, Tom Lane wrote: >> "Daniel Westermann (DWE)" writes: >> >> I was hoping someone more experienced with this would comment, but >> >> seeing none, I will apply it in a day or two to all supported versions? >> >> Have you tested this output back to 9.5? >> >> > I hoped that as well. No, I tested down to 9.6 because the change happened >> > in 10. >> >> The patch assumes that parallel query is enabled, which is not true by >> default before v10, so it should certainly not be applied before v10 >> (at least not without significant revisions). Yes, the behavior change was in 10. Before 10 the example is fine, I would not apply that to any prior version, otherwise the whole example needs to be rewritten. Regards Daniel
Re: Wrong example in the bloom documentation
Hi Bruce, >On Thu, Oct 8, 2020 at 06:34:32AM +0000, Daniel Westermann (DWE) wrote: >> Hi, >> >> as this does not get any attention on the docs-list, once again here. >> Any thoughts on this? >I was hoping someone more experienced with this would comment, but >seeing none, I will apply it in a day or two to all supported versions? >Have you tested this output back to 9.5? I hoped that as well. No, I tested down to 9.6 because the change happened in 10. Regards Daniel
Wrong example in the bloom documentation
Hi, as this does not get any attention on the docs-list, once again here. Any thoughts on this? Regards Daniel From: Daniel Westermann (DWE) Sent: Sunday, September 27, 2020 17:58 To: Pg Docs Subject: Wrong example in the bloom documentation Hi, I've briefly discussed this with Bruce some time ago in [1]. Replaying the example referenced in the documentation does not give a Bitmap Heap Scan on tbloom but a parallel seq scan with the default configuration: -- tested on head postgres=# CREATE TABLE tbloom AS postgres-# SELECT postgres-# (random() * 100)::int as i1, postgres-# (random() * 100)::int as i2, postgres-# (random() * 100)::int as i3, postgres-# (random() * 100)::int as i4, postgres-# (random() * 100)::int as i5, postgres-# (random() * 100)::int as i6 postgres-# FROM postgres-# generate_series(1,1000); SELECT 1000 postgres=# CREATE INDEX bloomidx ON tbloom USING bloom (i1, i2, i3, i4, i5, i6); CREATE INDEX postgres=# CREATE index btreeidx ON tbloom (i1, i2, i3, i4, i5, i6); CREATE INDEX postgres=# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451; QUERY PLAN - Gather (cost=1000.00..127220.00 rows=250 width=24) (actual time=2134.851..2221.836 rows=0 loops=1) Workers Planned: 2 Workers Launched: 2 -> Parallel Seq Scan on tbloom (cost=0.00..126195.00 rows=104 width=24) (actual time=1770.691..1770.692 rows=0 loops=3) Filter: ((i2 = 898732) AND (i5 = 123451)) Rows Removed by Filter: 333 Planning Time: 0.895 ms JIT: Functions: 6 Options: Inlining false, Optimization false, Expressions true, Deforming true Timing: Generation 65.512 ms, Inlining 0.000 ms, Optimization 46.328 ms, Emission 40.658 ms, Total 152.499 ms Execution Time: 2288.056 ms (12 rows) As bloom was introduced in 9.6 I quickly tried with 9.6.17 and indeed for this version the example is correct: postgres=# select version(); version -- PostgreSQL 9.6.17 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.3.1 20190507 (Red Hat 8.3.1-4), 64-bit (1 row) postgres=# CREATE TABLE tbloom AS postgres-# SELECT postgres-# (random() * 100)::int as i1, postgres-# (random() * 100)::int as i2, postgres-# (random() * 100)::int as i3, postgres-# (random() * 100)::int as i4, postgres-# (random() * 100)::int as i5, postgres-# (random() * 100)::int as i6 postgres-# FROM postgres-# generate_series(1,1000); SELECT 1000 postgres=# CREATE INDEX bloomidx ON tbloom USING bloom (i1, i2, i3, i4, i5, i6); CREATE INDEX postgres=# CREATE index btreeidx ON tbloom (i1, i2, i3, i4, i5, i6); CREATE INDEX postgres=# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451; QUERY PLAN --- Bitmap Heap Scan on tbloom (cost=178436.06..179392.83 rows=250 width=24) (actual time=2279.363..2279.363 rows=0 loops=1) Recheck Cond: ((i2 = 898732) AND (i5 = 123451)) Rows Removed by Index Recheck: 2329 Heap Blocks: exact=2288 -> Bitmap Index Scan on bloomidx (cost=0.00..178436.00 rows=250 width=0) (actual time=994.406..994.406 rows=2329 loops=1) Index Cond: ((i2 = 898732) AND (i5 = 123451)) Planning time: 282.059 ms Execution time: 2286.138 ms (8 rows) The reason is that parallel execution is disabled by default in 9.6, and if that is turned on the plan changes there as well: postgres=# set max_parallel_workers_per_gather = 2; SET postgres=# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451; QUERY PLAN --- Gather (cost=1000.00..127194.29 rows=1 width=24) (actual time=1148.047..1148.206 rows=0 loops=1) Workers Planned: 2 Workers Launched: 2 -> Parallel Seq Scan on tbloom (cost=0.00..126194.19 rows=1 width=24) (actual time=1039.501..1039.501 rows=0 loops=3) Filter: ((i2 = 898732) AND (i5 = 123451)) Rows Removed by Filter: 333 Planning time: 0.580 ms Execution time: 1148.247 ms (8 rows) Starting with PostgreSQL 10 the example in the documentation is
Re: Wrong sentence in the README?
"Daniel Westermann (DWE)" writes: >> in the README, top level, there is this: >> PostgreSQL has many language interfaces, many of which are listed here: >> https://www.postgresql.org/download >> I don't think the download page lists any language interfaces or do I miss >> something? >Not directly on that page, though if you drill down into the "software >catalogue" you can find them. >Since there's already a link to that same page a bit further down in >the file, I'm inclined to just remove the quoted sentence. Maybe >add something about "and related software" to the later link. Certainly >"language interfaces" is just one small part of that. Thank you, Tom. I'll try to come up with a patch for that in the next days. Regards Daniel
Wrong sentence in the README?
Hi, in the README, top level, there is this: PostgreSQL has many language interfaces, many of which are listed here: https://www.postgresql.org/download I don't think the download page lists any language interfaces or do I miss something? Regards Daniel
Re: Fw: Documentation fix for adding a column with a default value
>>The suggested change pares down the "Tip" to more of a brief "Note", which >>IMHO is a bit >>terse for that section of the documentation (which has more of a tutorial >>character), >>and the contents of the original tip basically still apply for volatile >>default values >>anyway. >> >>I've attached another suggestion for rewording this which should also make the >>mechanics of the operation a little clearer. >Thank you, that better explains it. Looks good to me. Shouldn't we add that to the current commit fest? Regards Daniel
Re: Fw: Documentation fix for adding a column with a default value
>> Seems the first mail didn't make it ... >Actually it did, I was about to reply to it :) > >The suggested change pares down the "Tip" to more of a brief "Note", which >IMHO is a bit >terse for that section of the documentation (which has more of a tutorial >character), >and the contents of the original tip basically still apply for volatile >default values >anyway. > >I've attached another suggestion for rewording this which should also make the >mechanics of the operation a little clearer. Thank you, that better explains it. Looks good to me. Regards Daniel
Fw: Documentation fix for adding a column with a default value
>__ >From: Daniel Westermann (DWE) >Sent: Monday, July 15, 2019 13:01 >To: pgsql-hack...@postgresql.org >Subject: Documentation fix for adding a column with a default value > >Hi, > >the tip in the "Adding a column" section is not true anymore since PostgreSQL >11: > >https://www.postgresql.org/docs/current/ddl-alter.html#DDL-ALTER-ADDING-A-COLUMN<https://www.postgresql.org/docs/current/ddl-alter.html#DDL-ALTER-ADDING-A-COLUMN> > >Attached a patch proposal for this. Seems the first mail didn't make it ... Regards Daniel diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 9301f0227d..62058ec3b1 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -1318,12 +1318,7 @@ ALTER TABLE products ADD COLUMN description text CHECK (description '') Adding a column with a default requires updating each row of the -table (to store the new column value). However, if no default is -specified, PostgreSQL is able to avoid -the physical update. So if you intend to fill the column with -mostly nondefault values, it's best to add the column with no default, -insert the correct values using UPDATE, and then add any -desired default as described below. +table (to store the new column value) if the default is volatile.
Documentation fix for adding a column with a default value
Hi, the tip in the "Adding a column" section is not true anymore since PostgreSQL 11: https://www.postgresql.org/docs/current/ddl-alter.html#DDL-ALTER-ADDING-A-COLUMN Attached a patch proposal for this. Regards Daniel diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 9301f0227d..62058ec3b1 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -1318,12 +1318,7 @@ ALTER TABLE products ADD COLUMN description text CHECK (description '') Adding a column with a default requires updating each row of the -table (to store the new column value). However, if no default is -specified, PostgreSQL is able to avoid -the physical update. So if you intend to fill the column with -mostly nondefault values, it's best to add the column with no default, -insert the correct values using UPDATE, and then add any -desired default as described below. +table (to store the new column value) if the default is volatile.
