pgsql: Add value 'current' for recovery_target_timeline
Add value 'current' for recovery_target_timeline This value represents the default behavior of using the current timeline. Previously, this was represented by an empty string. (Before the removal of recovery.conf, this setting could not be chosen explicitly but was used when recovery_target_timeline was not mentioned at all.) Discussion: https://www.postgresql.org/message-id/flat/[email protected]/ Reviewed-by: David Steele Reviewed-by: Michael Paquier Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ff85306055ede1fbca86ca4dfc4d48172342462b Modified Files -- doc/src/sgml/config.sgml | 8 +--- src/backend/utils/misc/guc.c | 4 ++-- src/backend/utils/misc/postgresql.conf.sample | 3 +-- 3 files changed, 8 insertions(+), 7 deletions(-)
pgsql: Create INSTALL file using Pandoc
Create INSTALL file using Pandoc Replace using lynx with using pandoc. Pandoc creates better looking output and it avoids the delicate locale/encoding issues of lynx because it always uses UTF-8 for both input and output. Note: requires Pandoc >=1.13 Discussion: https://www.postgresql.org/message-id/flat/[email protected]/ Reviewed-by: Mi Tar Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/96b8b8b6f9d8de4af01a77797273ad88c7a8e32e Modified Files -- doc/src/sgml/Makefile | 14 +++--- doc/src/sgml/docguide.sgml | 4 +++- 2 files changed, 6 insertions(+), 12 deletions(-)
pgsql: doc: Correct documentation of install-time environment variables
doc: Correct documentation of install-time environment variables Since approximately PostgreSQL 10, it is no longer required that environment variables at installation time such as PERL, PYTHON, TCLSH be "full path names", so change that phrasing in the installation instructions. (The exact time of change appears to differ for PERL and the others, but it works consistently in PostgreSQL 10.) Also while we're here document the defaults for PERL and PYTHON, but since the search list for TCLSH is so long, let's leave that out so we don't need to maintain a copy of that list in the installation instructions. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cbb3e08467fcb3d4ae01ee0c7758b40fe34a0eb5 Modified Files -- doc/src/sgml/installation.sgml | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-)
pgsql: doc: Correct documentation of install-time environment variables
doc: Correct documentation of install-time environment variables Since approximately PostgreSQL 10, it is no longer required that environment variables at installation time such as PERL, PYTHON, TCLSH be "full path names", so change that phrasing in the installation instructions. (The exact time of change appears to differ for PERL and the others, but it works consistently in PostgreSQL 10.) Also while we're here document the defaults for PERL and PYTHON, but since the search list for TCLSH is so long, let's leave that out so we don't need to maintain a copy of that list in the installation instructions. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c559d8dbf9e7871c64ecc976199cc89765a6cee8 Modified Files -- doc/src/sgml/installation.sgml | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-)
pgsql: doc: Correct documentation of install-time environment variables
doc: Correct documentation of install-time environment variables Since approximately PostgreSQL 10, it is no longer required that environment variables at installation time such as PERL, PYTHON, TCLSH be "full path names", so change that phrasing in the installation instructions. (The exact time of change appears to differ for PERL and the others, but it works consistently in PostgreSQL 10.) Also while we're here document the defaults for PERL and PYTHON, but since the search list for TCLSH is so long, let's leave that out so we don't need to maintain a copy of that list in the installation instructions. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8b89a88618dff78dec25f08ee0ca83824b69b34b Modified Files -- doc/src/sgml/installation.sgml | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-)
pgsql: Avoid sharing PARAM_EXEC slots between different levels of NestL
Avoid sharing PARAM_EXEC slots between different levels of NestLoop. Up to now, createplan.c attempted to share PARAM_EXEC slots for NestLoopParams across different plan levels, if the same underlying Var was being fed down to different righthand-side subplan trees by different NestLoops. This was, I think, more of an artifact of using subselect.c's PlannerParamItem infrastructure than an explicit design goal, but anyway that was the end result. This works well enough as long as the plan tree is executing synchronously, but the feature whereby Gather can execute the parallelized subplan locally breaks it. An upper NestLoop node might execute for a row retrieved from a parallel worker, and assign a value for a PARAM_EXEC slot from that row, while the leader's copy of the parallelized subplan is suspended with a different active value of the row the Var comes from. When control eventually returns to the leader's subplan, it gets the wrong answers if the same PARAM_EXEC slot is being used within the subplan, as reported in bug #15577 from Bartosz Polnik. This is pretty reminiscent of the problem fixed in commit 46c508fbc, and the proper fix seems to be the same: don't try to share PARAM_EXEC slots across different levels of controlling NestLoop nodes. This requires decoupling NestLoopParam handling from PlannerParamItem handling, although the logic remains somewhat similar. To avoid bizarre division of labor between subselect.c and createplan.c, I decided to move all the param-slot-assignment logic for both cases out of those files and put it into a new file paramassign.c. Hopefully it's a bit better documented now, too. A regression test case for this might be nice, but we don't know a test case that triggers the problem with a suitably small amount of data. Back-patch to 9.6 where we added Gather nodes. It's conceivable that related problems exist in older branches; but without some evidence for that, I'll leave the older branches alone. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/05eb923eae46c1698088d555ae590a73d4fc7070 Modified Files -- src/backend/optimizer/plan/createplan.c | 182 +- src/backend/optimizer/plan/planner.c | 9 +- src/backend/optimizer/plan/subselect.c | 387 ++-- src/backend/optimizer/util/Makefile | 3 +- src/backend/optimizer/util/paramassign.c | 599 +++ src/include/optimizer/paramassign.h | 34 ++ src/include/optimizer/subselect.h| 6 +- 7 files changed, 683 insertions(+), 537 deletions(-)
pgsql: Avoid sharing PARAM_EXEC slots between different levels of NestL
Avoid sharing PARAM_EXEC slots between different levels of NestLoop. Up to now, createplan.c attempted to share PARAM_EXEC slots for NestLoopParams across different plan levels, if the same underlying Var was being fed down to different righthand-side subplan trees by different NestLoops. This was, I think, more of an artifact of using subselect.c's PlannerParamItem infrastructure than an explicit design goal, but anyway that was the end result. This works well enough as long as the plan tree is executing synchronously, but the feature whereby Gather can execute the parallelized subplan locally breaks it. An upper NestLoop node might execute for a row retrieved from a parallel worker, and assign a value for a PARAM_EXEC slot from that row, while the leader's copy of the parallelized subplan is suspended with a different active value of the row the Var comes from. When control eventually returns to the leader's subplan, it gets the wrong answers if the same PARAM_EXEC slot is being used within the subplan, as reported in bug #15577 from Bartosz Polnik. This is pretty reminiscent of the problem fixed in commit 46c508fbc, and the proper fix seems to be the same: don't try to share PARAM_EXEC slots across different levels of controlling NestLoop nodes. This requires decoupling NestLoopParam handling from PlannerParamItem handling, although the logic remains somewhat similar. To avoid bizarre division of labor between subselect.c and createplan.c, I decided to move all the param-slot-assignment logic for both cases out of those files and put it into a new file paramassign.c. Hopefully it's a bit better documented now, too. A regression test case for this might be nice, but we don't know a test case that triggers the problem with a suitably small amount of data. Back-patch to 9.6 where we added Gather nodes. It's conceivable that related problems exist in older branches; but without some evidence for that, I'll leave the older branches alone. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1db5667bac63d0be825c375c4aeb8fb29b9a50bd Modified Files -- src/backend/optimizer/plan/createplan.c | 182 +- src/backend/optimizer/plan/planner.c | 9 +- src/backend/optimizer/plan/subselect.c | 396 ++-- src/backend/optimizer/util/Makefile | 6 +- src/backend/optimizer/util/paramassign.c | 599 +++ src/include/optimizer/paramassign.h | 34 ++ src/include/optimizer/subselect.h| 5 +- 7 files changed, 678 insertions(+), 553 deletions(-)
pgsql: Avoid sharing PARAM_EXEC slots between different levels of NestL
Avoid sharing PARAM_EXEC slots between different levels of NestLoop. Up to now, createplan.c attempted to share PARAM_EXEC slots for NestLoopParams across different plan levels, if the same underlying Var was being fed down to different righthand-side subplan trees by different NestLoops. This was, I think, more of an artifact of using subselect.c's PlannerParamItem infrastructure than an explicit design goal, but anyway that was the end result. This works well enough as long as the plan tree is executing synchronously, but the feature whereby Gather can execute the parallelized subplan locally breaks it. An upper NestLoop node might execute for a row retrieved from a parallel worker, and assign a value for a PARAM_EXEC slot from that row, while the leader's copy of the parallelized subplan is suspended with a different active value of the row the Var comes from. When control eventually returns to the leader's subplan, it gets the wrong answers if the same PARAM_EXEC slot is being used within the subplan, as reported in bug #15577 from Bartosz Polnik. This is pretty reminiscent of the problem fixed in commit 46c508fbc, and the proper fix seems to be the same: don't try to share PARAM_EXEC slots across different levels of controlling NestLoop nodes. This requires decoupling NestLoopParam handling from PlannerParamItem handling, although the logic remains somewhat similar. To avoid bizarre division of labor between subselect.c and createplan.c, I decided to move all the param-slot-assignment logic for both cases out of those files and put it into a new file paramassign.c. Hopefully it's a bit better documented now, too. A regression test case for this might be nice, but we don't know a test case that triggers the problem with a suitably small amount of data. Back-patch to 9.6 where we added Gather nodes. It's conceivable that related problems exist in older branches; but without some evidence for that, I'll leave the older branches alone. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2977a312df7121ac3caffd47ed2aae4eee8b1b80 Modified Files -- src/backend/optimizer/plan/createplan.c | 182 +- src/backend/optimizer/plan/planner.c | 9 +- src/backend/optimizer/plan/subselect.c | 370 ++-- src/backend/optimizer/util/Makefile | 3 +- src/backend/optimizer/util/paramassign.c | 582 +++ src/include/optimizer/paramassign.h | 34 ++ src/include/optimizer/subselect.h| 6 +- 7 files changed, 666 insertions(+), 520 deletions(-)
pgsql: Avoid sharing PARAM_EXEC slots between different levels of NestL
Avoid sharing PARAM_EXEC slots between different levels of NestLoop. Up to now, createplan.c attempted to share PARAM_EXEC slots for NestLoopParams across different plan levels, if the same underlying Var was being fed down to different righthand-side subplan trees by different NestLoops. This was, I think, more of an artifact of using subselect.c's PlannerParamItem infrastructure than an explicit design goal, but anyway that was the end result. This works well enough as long as the plan tree is executing synchronously, but the feature whereby Gather can execute the parallelized subplan locally breaks it. An upper NestLoop node might execute for a row retrieved from a parallel worker, and assign a value for a PARAM_EXEC slot from that row, while the leader's copy of the parallelized subplan is suspended with a different active value of the row the Var comes from. When control eventually returns to the leader's subplan, it gets the wrong answers if the same PARAM_EXEC slot is being used within the subplan, as reported in bug #15577 from Bartosz Polnik. This is pretty reminiscent of the problem fixed in commit 46c508fbc, and the proper fix seems to be the same: don't try to share PARAM_EXEC slots across different levels of controlling NestLoop nodes. This requires decoupling NestLoopParam handling from PlannerParamItem handling, although the logic remains somewhat similar. To avoid bizarre division of labor between subselect.c and createplan.c, I decided to move all the param-slot-assignment logic for both cases out of those files and put it into a new file paramassign.c. Hopefully it's a bit better documented now, too. A regression test case for this might be nice, but we don't know a test case that triggers the problem with a suitably small amount of data. Back-patch to 9.6 where we added Gather nodes. It's conceivable that related problems exist in older branches; but without some evidence for that, I'll leave the older branches alone. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4f80974990dce96771ef0e44c45999d8cc029c22 Modified Files -- src/backend/optimizer/plan/createplan.c | 178 +- src/backend/optimizer/plan/planner.c | 9 +- src/backend/optimizer/plan/subselect.c | 370 ++-- src/backend/optimizer/util/Makefile | 3 +- src/backend/optimizer/util/paramassign.c | 582 +++ src/include/optimizer/paramassign.h | 34 ++ src/include/optimizer/subselect.h| 6 +- 7 files changed, 664 insertions(+), 518 deletions(-)
pgsql: Free pre-modification HeapTuple in ALTER TABLE ... TYPE ...
Free pre-modification HeapTuple in ALTER TABLE ... TYPE ... This was an oversight in commit 3b174b1a3. Per offline gripe from Alvaro Herrera Backpatch to release 11. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/89d52b9a3e3fab3d6876c997370684a8b1c77f3b Modified Files -- src/backend/commands/tablecmds.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
pgsql: Free pre-modification HeapTuple in ALTER TABLE ... TYPE ...
Free pre-modification HeapTuple in ALTER TABLE ... TYPE ... This was an oversight in commit 3b174b1a3. Per offline gripe from Alvaro Herrera Backpatch to release 11. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e33884d4122b56fc0dbff3d8cedd8177334db838 Modified Files -- src/backend/commands/tablecmds.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
pgsql: Fix up confusion over how to use EXTRA_INSTALL.
Fix up confusion over how to use EXTRA_INSTALL. Some makefiles were trying to do this: temp-install: EXTRA_INSTALL=contrib/test_decoding but that no longer works as of commit aa019da52: the macro is now consulted by the checkprep target, one level down, and apparently gmake doesn't propagate such macro settings recursively. The problem is masked since 42e61c774 because pgxs.mk also sets up EXTRA_INSTALL, and correctly applies it to the checkprep target. Unfortunately I'd not risked back-patching that to before v11. Since aa019da52 was pushed back to v10, it broke test_decoding there (the only module for which this actually makes a difference at present). Hence, back-patch 42e61c774 to v10. Also, remove some demonstrably useless settings of EXTRA_INSTALL in v10 and v11 (they'd already been cleaned up in HEAD). Per buildfarm. Discussion: https://postgr.es/m/CAEepm=1pejdwv6dsgmofpx0eax7l7st28c1nxpqvqvmlfew...@mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/10ab85254d28a9347390405ee594d1b2f496912f Modified Files -- contrib/test_decoding/Makefile | 2 -- src/makefiles/pgxs.mk | 4 +++- src/test/modules/snapshot_too_old/Makefile | 2 -- src/test/recovery/Makefile | 2 -- 4 files changed, 3 insertions(+), 7 deletions(-)
pgsql: Fix up confusion over how to use EXTRA_INSTALL.
Fix up confusion over how to use EXTRA_INSTALL. Some makefiles were trying to do this: temp-install: EXTRA_INSTALL=contrib/test_decoding but that no longer works as of commit aa019da52: the macro is now consulted by the checkprep target, one level down, and apparently gmake doesn't propagate such macro settings recursively. The problem is masked since 42e61c774 because pgxs.mk also sets up EXTRA_INSTALL, and correctly applies it to the checkprep target. Unfortunately I'd not risked back-patching that to before v11. Since aa019da52 was pushed back to v10, it broke test_decoding there (the only module for which this actually makes a difference at present). Hence, back-patch 42e61c774 to v10. Also, remove some demonstrably useless settings of EXTRA_INSTALL in v10 and v11 (they'd already been cleaned up in HEAD). Per buildfarm. Discussion: https://postgr.es/m/CAEepm=1pejdwv6dsgmofpx0eax7l7st28c1nxpqvqvmlfew...@mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f285f23970dee5ab9ac67a415a41a3a19010be87 Modified Files -- contrib/test_decoding/Makefile | 2 -- src/test/modules/snapshot_too_old/Makefile | 2 -- 2 files changed, 4 deletions(-)
