pgsql: Fix compiler warning in multirange_constructor0()
Fix compiler warning in multirange_constructor0() Discussion: https://postgr.es/m/X%2BBP8XE0UpIB6Yvh%40paquier.xyz Author: Michael Paquier Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/29f8f546767ebb4253f6dc37815e2d95fff9acd0 Modified Files -- src/backend/utils/adt/multirangetypes.c | 16 1 file changed, 8 insertions(+), 8 deletions(-)
Re: pgsql: Multirange datatypes
Hi, Michael! On Mon, Dec 21, 2020 at 10:34 AM Michael Paquier wrote: > On Sun, Dec 20, 2020 at 04:21:16AM +, Alexander Korotkov wrote: > > Multirange datatypes > > > > Multiranges are basically sorted arrays of non-overlapping ranges with > > set-theoretic operations defined over them. > > This commit is creating a compilation warning on Windows: > multirangetypes.c(1033): warning C4715: 'multirange_constructor0' : > not all control paths return a value > > See for example woodlouse: > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=woodlouse&dt=2020-12-21%2001%3A42%3A28&stg=make > > Looking at the code, it is obvious that the compiler cannot understand > that this should always return. Please find attached a suggestion of > patch. Thank you for catching this! Pushed. -- Regards, Alexander Korotkov
Re: pgsql: Multirange datatypes
On Sun, Dec 20, 2020 at 11:02 PM Alexander Korotkov wrote: > On Sun, Dec 20, 2020 at 5:56 PM Alexander Korotkov > wrote: > > On Sun, Dec 20, 2020 at 4:37 PM Alexander Korotkov > > wrote: > > > On Sun, Dec 20, 2020 at 8:16 AM Alexander Korotkov > > > wrote: > > > There also appears to be some floating bug appearing here and there. > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gharial&dt=2020-12-20%2007%3A40%3A25 > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory&dt=2020-12-20%2004%3A25%3A18 > > > I'm investigating it. > > > > It seems that my commit is reliably crashing gharial. Could I get > > access to gharial to investigate this issue? > > No more need for this. I've managed to reproduce this locally. It > fails during selectivity estimation. Still investigating... Should be fixed by 4e1ee79e31. -- Regards, Alexander Korotkov
pgsql: Consider unsorted paths in generate_useful_gather_paths
Consider unsorted paths in generate_useful_gather_paths generate_useful_gather_paths used to skip unsorted paths (without any pathkeys), but that is unnecessary - the later code actually can handle such paths just fine by adding a Sort node. This is clearly a thinko, preventing construction of useful plans. Backpatch to 13, where Incremental Sort was introduced. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=h5m8lschj5e5oxp...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ea190ed14b4b75b38a490707d5d08231dcacfb8c Modified Files -- src/backend/optimizer/path/allpaths.c | 11 ++- src/test/regress/expected/incremental_sort.out | 13 + src/test/regress/sql/incremental_sort.sql | 4 3 files changed, 19 insertions(+), 9 deletions(-)
pgsql: Consider unsorted paths in generate_useful_gather_paths
Consider unsorted paths in generate_useful_gather_paths generate_useful_gather_paths used to skip unsorted paths (without any pathkeys), but that is unnecessary - the later code actually can handle such paths just fine by adding a Sort node. This is clearly a thinko, preventing construction of useful plans. Backpatch to 13, where Incremental Sort was introduced. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=h5m8lschj5e5oxp...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f4a3c0b06250ddc8ae09b59b87cf68e9bc0d7ca1 Modified Files -- src/backend/optimizer/path/allpaths.c | 11 ++- src/test/regress/expected/incremental_sort.out | 13 + src/test/regress/sql/incremental_sort.sql | 4 3 files changed, 19 insertions(+), 9 deletions(-)
pgsql: Check parallel safety in generate_useful_gather_paths
Check parallel safety in generate_useful_gather_paths Commit ebb7ae839d ensured we ignore pathkeys with volatile expressions when considering adding a sort below a Gather Merge. Turns out we need to care about parallel safety of the pathkeys too, otherwise we might try sorting e.g. on results of a correlated subquery (as demonstrated by a report from Luis Roberto). Initial investigation by Tom Lane, patch by James Coleman. Backpatch to 13, where the code was instroduced (as part of Incremental Sort). Reported-by: Luis Roberto Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/622580997.37108180.1604080457319.JavaMail.zimbra%40siscobra.com.br Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=h5m8lschj5e5oxp...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/be9c3cd186ba86b9bc3df7ecc64b81ce4726810d Modified Files -- src/backend/optimizer/path/allpaths.c | 13 +++-- src/backend/optimizer/path/equivclass.c| 9 +- src/include/optimizer/paths.h | 5 +++- src/test/regress/expected/incremental_sort.out | 40 ++ src/test/regress/sql/incremental_sort.sql | 11 +++ 5 files changed, 73 insertions(+), 5 deletions(-)
pgsql: Check parallel safety in generate_useful_gather_paths
Check parallel safety in generate_useful_gather_paths Commit ebb7ae839d ensured we ignore pathkeys with volatile expressions when considering adding a sort below a Gather Merge. Turns out we need to care about parallel safety of the pathkeys too, otherwise we might try sorting e.g. on results of a correlated subquery (as demonstrated by a report from Luis Roberto). Initial investigation by Tom Lane, patch by James Coleman. Backpatch to 13, where the code was instroduced (as part of Incremental Sort). Reported-by: Luis Roberto Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/622580997.37108180.1604080457319.JavaMail.zimbra%40siscobra.com.br Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=h5m8lschj5e5oxp...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/86b7cca72d4d0a4e043fac0a2cdd56218ff2f258 Modified Files -- src/backend/optimizer/path/allpaths.c | 13 +++-- src/backend/optimizer/path/equivclass.c| 9 +- src/include/optimizer/paths.h | 5 +++- src/test/regress/expected/incremental_sort.out | 40 ++ src/test/regress/sql/incremental_sort.sql | 11 +++ 5 files changed, 73 insertions(+), 5 deletions(-)
pgsql: Remove "invalid concatenation of jsonb objects" error case.
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let's just remove the restriction, creating a uniform rule that unless we are handling an object-to-object concatenation, non-array inputs are converted to one-element arrays, resulting in an array-to-array concatenation. (This does not change the behavior for any case that didn't throw an error before.) Per complaint from Joel Jacobson. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ff5d5611c01f60525c30b2c3ebc16d05edb7956d Modified Files -- doc/src/sgml/func.sgml | 22 +++- src/backend/utils/adt/jsonfuncs.c | 71 ++--- src/test/regress/expected/jsonb.out | 36 +-- src/test/regress/sql/jsonb.sql | 5 +++ 4 files changed, 94 insertions(+), 40 deletions(-)
pgsql: Remove "invalid concatenation of jsonb objects" error case.
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let's just remove the restriction, creating a uniform rule that unless we are handling an object-to-object concatenation, non-array inputs are converted to one-element arrays, resulting in an array-to-array concatenation. (This does not change the behavior for any case that didn't throw an error before.) Per complaint from Joel Jacobson. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/75c8ef5ae56c5d9fad594b65eaa3bb8024f7f24f Modified Files -- doc/src/sgml/func.sgml | 11 +++-- src/backend/utils/adt/jsonfuncs.c | 83 + src/test/regress/expected/jsonb.out | 36 +++- src/test/regress/sql/jsonb.sql | 5 +++ 4 files changed, 85 insertions(+), 50 deletions(-)
pgsql: Remove "invalid concatenation of jsonb objects" error case.
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let's just remove the restriction, creating a uniform rule that unless we are handling an object-to-object concatenation, non-array inputs are converted to one-element arrays, resulting in an array-to-array concatenation. (This does not change the behavior for any case that didn't throw an error before.) Per complaint from Joel Jacobson. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1d5f3f976b26271b51a619f02436ec5c263db9f3 Modified Files -- doc/src/sgml/func.sgml | 11 +++-- src/backend/utils/adt/jsonfuncs.c | 85 + src/test/regress/expected/jsonb.out | 36 +++- src/test/regress/sql/jsonb.sql | 5 +++ 4 files changed, 86 insertions(+), 51 deletions(-)
pgsql: Remove "invalid concatenation of jsonb objects" error case.
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let's just remove the restriction, creating a uniform rule that unless we are handling an object-to-object concatenation, non-array inputs are converted to one-element arrays, resulting in an array-to-array concatenation. (This does not change the behavior for any case that didn't throw an error before.) Per complaint from Joel Jacobson. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/38d30a14b05e0cc2996fd311d94d7ae4fe2122aa Modified Files -- doc/src/sgml/func.sgml | 22 +- src/backend/utils/adt/jsonfuncs.c | 83 + src/test/regress/expected/jsonb.out | 36 +++- src/test/regress/sql/jsonb.sql | 5 +++ 4 files changed, 99 insertions(+), 47 deletions(-)
pgsql: Remove "invalid concatenation of jsonb objects" error case.
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let's just remove the restriction, creating a uniform rule that unless we are handling an object-to-object concatenation, non-array inputs are converted to one-element arrays, resulting in an array-to-array concatenation. (This does not change the behavior for any case that didn't throw an error before.) Per complaint from Joel Jacobson. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/38bef9e433eff68ffbfcf0a52ba7c2dc83c7466d Modified Files -- doc/src/sgml/func.sgml | 11 +++-- src/backend/utils/adt/jsonfuncs.c | 83 + src/test/regress/expected/jsonb.out | 36 +++- src/test/regress/sql/jsonb.sql | 5 +++ 4 files changed, 85 insertions(+), 50 deletions(-)
pgsql: Remove "invalid concatenation of jsonb objects" error case.
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let's just remove the restriction, creating a uniform rule that unless we are handling an object-to-object concatenation, non-array inputs are converted to one-element arrays, resulting in an array-to-array concatenation. (This does not change the behavior for any case that didn't throw an error before.) Per complaint from Joel Jacobson. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/542248f9ddfd49f268b2edc4b6beeff7cf0b6aba Modified Files -- doc/src/sgml/func.sgml | 11 +++-- src/backend/utils/adt/jsonfuncs.c | 85 + src/test/regress/expected/jsonb.out | 36 +++- src/test/regress/sql/jsonb.sql | 5 +++ 4 files changed, 86 insertions(+), 51 deletions(-)
pgsql: Remove "invalid concatenation of jsonb objects" error case.
Remove "invalid concatenation of jsonb objects" error case. The jsonb || jsonb operator arbitrarily rejected certain combinations of scalar and non-scalar inputs, while being willing to concatenate other combinations. This was of course quite undocumented. Rather than trying to document it, let's just remove the restriction, creating a uniform rule that unless we are handling an object-to-object concatenation, non-array inputs are converted to one-element arrays, resulting in an array-to-array concatenation. (This does not change the behavior for any case that didn't throw an error before.) Per complaint from Joel Jacobson. Back-patch to all supported branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/edcdbc44eed2eae5c7b40a051998e32ecf4f8f12 Modified Files -- doc/src/sgml/func.sgml | 11 +++-- src/backend/utils/adt/jsonfuncs.c | 85 + src/test/regress/expected/jsonb.out | 36 +++- src/test/regress/sql/jsonb.sql | 5 +++ 4 files changed, 86 insertions(+), 51 deletions(-)
pgsql: Disallow SRFs when considering sorts below Gather Merge
Disallow SRFs when considering sorts below Gather Merge While we do allow SRFs in ORDER BY, scan/join processing should not consider such cases - such sorts should only happen via final Sort atop a ProjectSet. So make sure we don't try adding such sorts below Gather Merge, just like we do for expressions that are volatile and/or not parallel safe. Backpatch to PostgreSQL 13, where this code was introduced as part of the Incremental Sort patch. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=h5m8lschj5e5oxp...@mail.gmail.com Discussion: https://postgr.es/m/295524.1606246314%40sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fac1b470a9f7e846534620b78ea4cf122ed432b2 Modified Files -- src/backend/optimizer/path/equivclass.c| 7 +++ src/backend/optimizer/util/tlist.c | 5 - src/include/optimizer/optimizer.h | 5 + src/test/regress/expected/incremental_sort.out | 12 src/test/regress/sql/incremental_sort.sql | 2 ++ 5 files changed, 26 insertions(+), 5 deletions(-)
pgsql: Disallow SRFs when considering sorts below Gather Merge
Disallow SRFs when considering sorts below Gather Merge While we do allow SRFs in ORDER BY, scan/join processing should not consider such cases - such sorts should only happen via final Sort atop a ProjectSet. So make sure we don't try adding such sorts below Gather Merge, just like we do for expressions that are volatile and/or not parallel safe. Backpatch to PostgreSQL 13, where this code was introduced as part of the Incremental Sort patch. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=h5m8lschj5e5oxp...@mail.gmail.com Discussion: https://postgr.es/m/295524.1606246314%40sss.pgh.pa.us Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d0167631e8b7388b78203c6798621f98beed93d5 Modified Files -- src/backend/optimizer/path/equivclass.c| 7 +++ src/backend/optimizer/util/tlist.c | 5 - src/include/optimizer/optimizer.h | 5 + src/test/regress/expected/incremental_sort.out | 12 src/test/regress/sql/incremental_sort.sql | 2 ++ 5 files changed, 26 insertions(+), 5 deletions(-)
pgsql: Don't search for volatile expr in find_em_expr_usable_for_sortin
Don't search for volatile expr in find_em_expr_usable_for_sorting_rel While prepare_sort_from_pathkeys has to be concerned about matching up a volatile expression to the proper tlist entry, we don't need to do that in find_em_expr_usable_for_sorting_rel becausee such a sort will have to be postponed anyway. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs%3DhC0mSksZC%3DH5M8LSchj5e5OxpTAg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9aff4dc01fbb9e126efafd839ae8541362328f1a Modified Files -- src/backend/optimizer/path/equivclass.c | 28 +--- 1 file changed, 5 insertions(+), 23 deletions(-)
pgsql: Don't search for volatile expr in find_em_expr_usable_for_sortin
Don't search for volatile expr in find_em_expr_usable_for_sorting_rel While prepare_sort_from_pathkeys has to be concerned about matching up a volatile expression to the proper tlist entry, we don't need to do that in find_em_expr_usable_for_sorting_rel becausee such a sort will have to be postponed anyway. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs%3DhC0mSksZC%3DH5M8LSchj5e5OxpTAg%40mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aa97890b6ec2ad07700c6e4825022ae3979ece7f Modified Files -- src/backend/optimizer/path/equivclass.c | 28 +--- 1 file changed, 5 insertions(+), 23 deletions(-)
pgsql: Improve find_em_expr_usable_for_sorting_rel comment
Improve find_em_expr_usable_for_sorting_rel comment Clarify the relationship between find_em_expr_usable_for_sorting_rel and prepare_sort_from_pathkeys, i.e. what restrictions need to be shared between those two places. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs%3DhC0mSksZC%3DH5M8LSchj5e5OxpTAg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1ca2eb103113d64930cf1120ba2beaaebd1076f4 Modified Files -- src/backend/optimizer/path/equivclass.c | 8 +--- src/backend/optimizer/plan/createplan.c | 3 +++ 2 files changed, 8 insertions(+), 3 deletions(-)
pgsql: Improve find_em_expr_usable_for_sorting_rel comment
Improve find_em_expr_usable_for_sorting_rel comment Clarify the relationship between find_em_expr_usable_for_sorting_rel and prepare_sort_from_pathkeys, i.e. what restrictions need to be shared between those two places. Author: James Coleman Reviewed-by: Tomas Vondra Backpatch-through: 13 Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs%3DhC0mSksZC%3DH5M8LSchj5e5OxpTAg%40mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/336879f5557e6bb1f6c8d7837fd8b87158441078 Modified Files -- src/backend/optimizer/path/equivclass.c | 8 +--- src/backend/optimizer/plan/createplan.c | 3 +++ 2 files changed, 8 insertions(+), 3 deletions(-)
Re: pgsql: Multirange datatypes
On Mon, Dec 21, 2020 at 02:31:44PM +0300, Alexander Korotkov wrote: > Thank you for catching this! Pushed. Thanks for the commit, Alexander. -- Michael signature.asc Description: PGP signature
