pgsql: Fix generate_partitionwise_join_paths() to tolerate failure.
Fix generate_partitionwise_join_paths() to tolerate failure. We might fail to generate a partitionwise join, because reparameterize_path_by_child() does not support all path types. This should not be a hard failure condition: we should just fall back to a non-partitioned join. However, generate_partitionwise_join_paths did not consider this possibility and would emit the (misleading) error "could not devise a query plan for the given query" if we'd failed to make any paths for a child join. Fix it to give up on partitionwise joining if so. (The accepted technique for giving up appears to be to set rel->nparts = 0, which I find pretty bizarre, but there you have it.) I have not added a test case because there'd be little point: any omissions of this sort that we identify would soon get fixed by extending reparameterize_path_by_child(), so the test would stop proving anything. However, right now there is a known test case based on failure to cover MaterialPath, and with that I've found that this is broken in all supported versions. Hence, patch all the way back. Original report and patch by me; thanks to Richard Guo for identifying a test case that works against committed versions. Discussion: https://postgr.es/m/[email protected] Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bf8fd64ff5e65f8964d1b52c50019f0198ec5f5e Modified Files -- src/backend/optimizer/path/allpaths.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-)
pgsql: Fix generate_partitionwise_join_paths() to tolerate failure.
Fix generate_partitionwise_join_paths() to tolerate failure. We might fail to generate a partitionwise join, because reparameterize_path_by_child() does not support all path types. This should not be a hard failure condition: we should just fall back to a non-partitioned join. However, generate_partitionwise_join_paths did not consider this possibility and would emit the (misleading) error "could not devise a query plan for the given query" if we'd failed to make any paths for a child join. Fix it to give up on partitionwise joining if so. (The accepted technique for giving up appears to be to set rel->nparts = 0, which I find pretty bizarre, but there you have it.) I have not added a test case because there'd be little point: any omissions of this sort that we identify would soon get fixed by extending reparameterize_path_by_child(), so the test would stop proving anything. However, right now there is a known test case based on failure to cover MaterialPath, and with that I've found that this is broken in all supported versions. Hence, patch all the way back. Original report and patch by me; thanks to Richard Guo for identifying a test case that works against committed versions. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fe12f2f8fa608156c2d3c027cdd6aa9af0788e3a Modified Files -- src/backend/optimizer/path/allpaths.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-)
pgsql: Add missing MaterialPath support in reparameterize_path[_by_chil
Add missing MaterialPath support in reparameterize_path[_by_child]. These two functions failed to cover MaterialPath. That's not a fatal problem, but we can generate better plans in some cases if we support it. Tom Lane and Richard Guo Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6eb2f0ed4cd5c8668c3127024a8a58b10fa2e8dc Modified Files -- src/backend/optimizer/util/pathnode.c | 25 - 1 file changed, 24 insertions(+), 1 deletion(-)
pgsql: Fix generate_partitionwise_join_paths() to tolerate failure.
Fix generate_partitionwise_join_paths() to tolerate failure. We might fail to generate a partitionwise join, because reparameterize_path_by_child() does not support all path types. This should not be a hard failure condition: we should just fall back to a non-partitioned join. However, generate_partitionwise_join_paths did not consider this possibility and would emit the (misleading) error "could not devise a query plan for the given query" if we'd failed to make any paths for a child join. Fix it to give up on partitionwise joining if so. (The accepted technique for giving up appears to be to set rel->nparts = 0, which I find pretty bizarre, but there you have it.) I have not added a test case because there'd be little point: any omissions of this sort that we identify would soon get fixed by extending reparameterize_path_by_child(), so the test would stop proving anything. However, right now there is a known test case based on failure to cover MaterialPath, and with that I've found that this is broken in all supported versions. Hence, patch all the way back. Original report and patch by me; thanks to Richard Guo for identifying a test case that works against committed versions. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4ebca555cf238628b933f79fd90fdd41bed4d39d Modified Files -- src/backend/optimizer/path/allpaths.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-)
pgsql: Fix generate_partitionwise_join_paths() to tolerate failure.
Fix generate_partitionwise_join_paths() to tolerate failure. We might fail to generate a partitionwise join, because reparameterize_path_by_child() does not support all path types. This should not be a hard failure condition: we should just fall back to a non-partitioned join. However, generate_partitionwise_join_paths did not consider this possibility and would emit the (misleading) error "could not devise a query plan for the given query" if we'd failed to make any paths for a child join. Fix it to give up on partitionwise joining if so. (The accepted technique for giving up appears to be to set rel->nparts = 0, which I find pretty bizarre, but there you have it.) I have not added a test case because there'd be little point: any omissions of this sort that we identify would soon get fixed by extending reparameterize_path_by_child(), so the test would stop proving anything. However, right now there is a known test case based on failure to cover MaterialPath, and with that I've found that this is broken in all supported versions. Hence, patch all the way back. Original report and patch by me; thanks to Richard Guo for identifying a test case that works against committed versions. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1ff549e844cc649b5f4f1bbab88404aaffebbfa4 Modified Files -- src/backend/optimizer/path/allpaths.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-)
pgsql: Fix broken MemoizePath support in reparameterize_path().
Fix broken MemoizePath support in reparameterize_path(). It neglected to recurse to the subpath, meaning you'd get back a path identical to the input. This could produce wrong query results if the omission meant that the subpath fails to enforce some join clause it should be enforcing. We don't have a test case for this at the moment, but the code is obviously broken and the fix is equally obvious. Back-patch to v14 where Memoize was introduced. Richard Guo Discussion: https://postgr.es/m/CAMbWs4_R=ORpz=lkn2q3ebpc5euwyfzf+tmfcpvlbvk5w39...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e76913802c5347831aadc1513b59196bde6ec116 Modified Files -- src/backend/optimizer/util/pathnode.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-)
pgsql: Fix generate_partitionwise_join_paths() to tolerate failure.
Fix generate_partitionwise_join_paths() to tolerate failure. We might fail to generate a partitionwise join, because reparameterize_path_by_child() does not support all path types. This should not be a hard failure condition: we should just fall back to a non-partitioned join. However, generate_partitionwise_join_paths did not consider this possibility and would emit the (misleading) error "could not devise a query plan for the given query" if we'd failed to make any paths for a child join. Fix it to give up on partitionwise joining if so. (The accepted technique for giving up appears to be to set rel->nparts = 0, which I find pretty bizarre, but there you have it.) I have not added a test case because there'd be little point: any omissions of this sort that we identify would soon get fixed by extending reparameterize_path_by_child(), so the test would stop proving anything. However, right now there is a known test case based on failure to cover MaterialPath, and with that I've found that this is broken in all supported versions. Hence, patch all the way back. Original report and patch by me; thanks to Richard Guo for identifying a test case that works against committed versions. Discussion: https://postgr.es/m/[email protected] Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ec3daeec316ff999d3e8f12a3587cdb4d0af81b0 Modified Files -- src/backend/optimizer/path/allpaths.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-)
pgsql: Fix broken MemoizePath support in reparameterize_path().
Fix broken MemoizePath support in reparameterize_path(). It neglected to recurse to the subpath, meaning you'd get back a path identical to the input. This could produce wrong query results if the omission meant that the subpath fails to enforce some join clause it should be enforcing. We don't have a test case for this at the moment, but the code is obviously broken and the fix is equally obvious. Back-patch to v14 where Memoize was introduced. Richard Guo Discussion: https://postgr.es/m/CAMbWs4_R=ORpz=lkn2q3ebpc5euwyfzf+tmfcpvlbvk5w39...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/834d97c32b712c170594378d27385638c5b87c60 Modified Files -- src/backend/optimizer/util/pathnode.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-)
pgsql: Fix broken MemoizePath support in reparameterize_path().
Fix broken MemoizePath support in reparameterize_path(). It neglected to recurse to the subpath, meaning you'd get back a path identical to the input. This could produce wrong query results if the omission meant that the subpath fails to enforce some join clause it should be enforcing. We don't have a test case for this at the moment, but the code is obviously broken and the fix is equally obvious. Back-patch to v14 where Memoize was introduced. Richard Guo Discussion: https://postgr.es/m/CAMbWs4_R=ORpz=lkn2q3ebpc5euwyfzf+tmfcpvlbvk5w39...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ce093aa18062f64d5eb16175e361cc34a222c1db Modified Files -- src/backend/optimizer/util/pathnode.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-)
pgsql: Fix generate_partitionwise_join_paths() to tolerate failure.
Fix generate_partitionwise_join_paths() to tolerate failure. We might fail to generate a partitionwise join, because reparameterize_path_by_child() does not support all path types. This should not be a hard failure condition: we should just fall back to a non-partitioned join. However, generate_partitionwise_join_paths did not consider this possibility and would emit the (misleading) error "could not devise a query plan for the given query" if we'd failed to make any paths for a child join. Fix it to give up on partitionwise joining if so. (The accepted technique for giving up appears to be to set rel->nparts = 0, which I find pretty bizarre, but there you have it.) I have not added a test case because there'd be little point: any omissions of this sort that we identify would soon get fixed by extending reparameterize_path_by_child(), so the test would stop proving anything. However, right now there is a known test case based on failure to cover MaterialPath, and with that I've found that this is broken in all supported versions. Hence, patch all the way back. Original report and patch by me; thanks to Richard Guo for identifying a test case that works against committed versions. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2df073313934a3787ec0e42dde4a06a879ae5e3a Modified Files -- src/backend/optimizer/path/allpaths.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-)
pgsql: Re-pgindent a few files.
Re-pgindent a few files. Just because I'm a neatnik, and I'm currently working on code in this area. It annoys me to not be able to pgindent my patches without working around unrelated changes. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/92c4dafe1eed511c5af92bcea5311cf627673377 Modified Files -- src/backend/optimizer/plan/setrefs.c | 4 ++-- src/backend/utils/adt/selfuncs.c | 2 +- src/include/nodes/parsenodes.h | 4 ++-- src/include/nodes/plannodes.h| 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-)
pgsql: Update top-level .gitignore.
Update top-level .gitignore. Add a comment explaining our policy that we don't put excludes for nonstandard tools into committed .gitignore files. Also, remove the entries about libraries with .sl extensions, since that convention was only used on now-desupported HP-UX. Discussion: https://postgr.es/m/cahxw8baiypwfxbn813ghorqozwmbs4f3dtxlkknxigqujuw...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d94f32d49f620fb08c1fd0e8c9345844ccd9b7c0 Modified Files -- .gitignore | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Fix thinko introduced in 6b423ec67
Fix thinko introduced in 6b423ec67 As pointed out by Dean Rasheed, we really should be using tmp > -(PG_INTNN_MIN / 10) rather than tmp > (PG_INTNN_MAX / 10) for checking for overflows in the accumulation in the pg_strtointNN functions. This does happen to be the same number when dividing by 10, but there is a pending patch which adds other bases and this is not the same number if we were to divide by 2 rather than 10, for example. If the base 2 parsing was to follow this example then we could accidentally think a string containing the value of PG_INT32_MIN was an overflow in pg_strtoint32. Clearly that shouldn't overflow. This does not fix any actual live bugs, only some bad examples of overflow checks for future bases. Reported-by: Dean Rasheed Discussion: https://postgr.es/m/CAEZATCVEtwfhdm-K-etZYFB0=qsr0nt6qxta_w+gqx4ryph...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8692f6644e71f51db9a853a652f37909c9cb534d Modified Files -- src/backend/utils/adt/numutils.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Add LSN location in some error messages related to WAL pages
Add LSN location in some error messages related to WAL pages The error messages reported during any failures while reading or validating the header of a WAL currently includes only the offset of the page but not the compiled LSN referring to the page, requiring an extra step to compile it if looking at the surroundings with pg_waldump or similar. Adding this information costs a bit in translation, but also eases debugging. Author: Bharath Rupireddy Reviewed-by: Álvaro Herrera, Kyotaro Horiguchi, Maxim Orlov, Michael Paquier Discussion: https://postgr.es/m/CALj2ACWV=FCddsxcGbVOA=cvPyMr75YCFbSQT6g4KDj=gcj...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/71cb84ec69a38444c48bd8d3b5451b2da157848b Modified Files -- src/backend/access/transam/xlogreader.c | 15 ++- src/backend/access/transam/xlogrecovery.c | 13 - 2 files changed, 18 insertions(+), 10 deletions(-)
pgsql: doc: Add missing markups for developer GUCs
doc: Add missing markups for developer GUCs Missing such markups makes it impossible to create links back to these GUCs, and all the other parameters have one already. Author: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=jx=6dfb_en3j0ukuvg3cpu5omqim-zkraz+fkvs+u...@mail.gmail.com Backpatch-through: 11 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8a476fda5e45f16d8c608c73d9e871bd4023d79a Modified Files -- doc/src/sgml/config.sgml | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-)
pgsql: doc: Add missing markups for developer GUCs
doc: Add missing markups for developer GUCs Missing such markups makes it impossible to create links back to these GUCs, and all the other parameters have one already. Author: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=jx=6dfb_en3j0ukuvg3cpu5omqim-zkraz+fkvs+u...@mail.gmail.com Backpatch-through: 11 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/990a773ab6a807f3436d86b2825435f1274a8187 Modified Files -- doc/src/sgml/config.sgml | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-)
pgsql: doc: Add missing markups for developer GUCs
doc: Add missing markups for developer GUCs Missing such markups makes it impossible to create links back to these GUCs, and all the other parameters have one already. Author: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=jx=6dfb_en3j0ukuvg3cpu5omqim-zkraz+fkvs+u...@mail.gmail.com Backpatch-through: 11 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1bd84ef6778017f89c2ca80377c3ae02ed3f4861 Modified Files -- doc/src/sgml/config.sgml | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-)
pgsql: doc: Add missing markups for developer GUCs
doc: Add missing markups for developer GUCs Missing such markups makes it impossible to create links back to these GUCs, and all the other parameters have one already. Author: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=jx=6dfb_en3j0ukuvg3cpu5omqim-zkraz+fkvs+u...@mail.gmail.com Backpatch-through: 11 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/74a600a1506113cce67aa2d5b869ad69459a8ccd Modified Files -- doc/src/sgml/config.sgml | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-)
pgsql: doc: Add missing markups for developer GUCs
doc: Add missing markups for developer GUCs Missing such markups makes it impossible to create links back to these GUCs, and all the other parameters have one already. Author: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=jx=6dfb_en3j0ukuvg3cpu5omqim-zkraz+fkvs+u...@mail.gmail.com Backpatch-through: 11 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/84e6188d68f421523f4a25e9132e8e4fa9700648 Modified Files -- doc/src/sgml/config.sgml | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-)
pgsql: doc: Add missing markups for developer GUCs
doc: Add missing markups for developer GUCs Missing such markups makes it impossible to create links back to these GUCs, and all the other parameters have one already. Author: Ian Lawrence Barwick Discussion: https://postgr.es/m/CAB8KJ=jx=6dfb_en3j0ukuvg3cpu5omqim-zkraz+fkvs+u...@mail.gmail.com Backpatch-through: 11 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/afd096e9aeb02f0e3e88054d1bb2a0ed966ac5f6 Modified Files -- doc/src/sgml/config.sgml | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-)
