pgsql: Remove extra word from src/backend/optimizer/README
Remove extra word from src/backend/optimizer/README Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2e39f69b6621bd3d67f650a5647fd0412819712d Modified Files -- src/backend/optimizer/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove extra word from src/backend/optimizer/README
Remove extra word from src/backend/optimizer/README Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/40e981391395ae93aadfaf08cd343af65cc6252b Modified Files -- src/backend/optimizer/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix pg_verify_checksums on Windows.
Fix pg_verify_checksums on Windows. To verify the checksums, we open the file in text mode which doesn't work on Windows as WIN32 treats Control-Z as EOF in files opened in text mode. This leads to "short read of block .." error in some cases. Fix it by opening the files in the binary mode. Author: Amit Kapila Reviewed-by: Magnus Hagander Backpatch-through: 11 Discussion: https://postgr.es/m/caa4ek1+lonzod+h85fgmyjwzxky-xv1fyweyp-tky2wpd5c...@mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/762a16572bb5d9be6c9c53c9ecd29288da213d02 Modified Files -- src/bin/pg_verify_checksums/pg_verify_checksums.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix pg_verify_checksums on Windows.
Fix pg_verify_checksums on Windows. To verify the checksums, we open the file in text mode which doesn't work on Windows as WIN32 treats Control-Z as EOF in files opened in text mode. This leads to "short read of block .." error in some cases. Fix it by opening the files in the binary mode. Author: Amit Kapila Reviewed-by: Magnus Hagander Backpatch-through: 11 Discussion: https://postgr.es/m/caa4ek1+lonzod+h85fgmyjwzxky-xv1fyweyp-tky2wpd5c...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bb60f2cb6ed8361fbf18b92d312776046d9b0103 Modified Files -- src/bin/pg_verify_checksums/pg_verify_checksums.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Disable support for partitionwise joins in problematic cases.
Disable support for partitionwise joins in problematic cases. Commit f49842d, which added support for partitionwise joins, built the child's tlist by applying adjust_appendrel_attrs() to the parent's. So in the case where the parent's included a whole-row Var for the parent, the child's contained a ConvertRowtypeExpr. To cope with that, that commit added code to the planner, such as setrefs.c, but some code paths still assumed that the tlist for a scan (or join) rel would only include Vars and PlaceHolderVars, which was true before that commit, causing errors: * When creating an explicit sort node for an input path for a mergejoin path for a child join, prepare_sort_from_pathkeys() threw the 'could not find pathkey item to sort' error. * When deparsing a relation participating in a pushed down child join as a subquery in contrib/postgres_fdw, get_relation_column_alias_ids() threw the 'unexpected expression in subquery output' error. * When performing set_plan_references() on a local join plan generated by contrib/postgres_fdw for EvalPlanQual support for a pushed down child join, fix_join_expr() threw the 'variable not found in subplan target lists' error. To fix these, two approaches have been proposed: one by Ashutosh Bapat and one by me. While the former keeps building the child's tlist with a ConvertRowtypeExpr, the latter builds it with a whole-row Var for the child not to violate the planner assumption, and tries to fix it up later, But both approaches need more work, so refuse to generate partitionwise join paths when whole-row Vars are involved, instead. We don't need to handle ConvertRowtypeExprs in the child's tlists for now, so this commit also removes the changes to the planner. Previously, partitionwise join computed attr_needed data for each child separately, and built the child join's tlist using that data, which also required an extra step for adding PlaceHolderVars to that tlist, but it would be more efficient to build it from the parent join's tlist through the adjust_appendrel_attrs() transformation. So this commit builds that list that way, and simplifies build_joinrel_tlist() and placeholder.c as well as part of set_append_rel_size() to basically what they were before partitionwise join went in. Back-patch to PG11 where partitionwise join was introduced. Report by Rajkumar Raghuwanshi. Analysis by Ashutosh Bapat, who also provided some of regression tests. Patch by me, reviewed by Robert Haas. Discussion: https://postgr.es/m/cakcux6ktu-8teflwtquuzbyfaza83vuzurd7c1yhc-yewyy...@mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/940487956ede2a6d0fb98b0b92cbf1f4656baaf0 Modified Files -- contrib/postgres_fdw/expected/postgres_fdw.out| 71 +--- contrib/postgres_fdw/sql/postgres_fdw.sql | 14 ++- src/backend/nodes/outfuncs.c | 1 + src/backend/optimizer/path/allpaths.c | 78 ++ src/backend/optimizer/path/joinrels.c | 7 ++ src/backend/optimizer/plan/setrefs.c | 58 +- src/backend/optimizer/util/placeholder.c | 58 -- src/backend/optimizer/util/relnode.c | 125 +++--- src/include/nodes/relation.h | 8 +- src/test/regress/expected/partition_aggregate.out | 32 ++ src/test/regress/expected/partition_join.out | 57 +++--- src/test/regress/sql/partition_aggregate.sql | 5 + src/test/regress/sql/partition_join.sql | 8 +- 13 files changed, 266 insertions(+), 256 deletions(-)
pgsql: Disable support for partitionwise joins in problematic cases.
Disable support for partitionwise joins in problematic cases. Commit f49842d, which added support for partitionwise joins, built the child's tlist by applying adjust_appendrel_attrs() to the parent's. So in the case where the parent's included a whole-row Var for the parent, the child's contained a ConvertRowtypeExpr. To cope with that, that commit added code to the planner, such as setrefs.c, but some code paths still assumed that the tlist for a scan (or join) rel would only include Vars and PlaceHolderVars, which was true before that commit, causing errors: * When creating an explicit sort node for an input path for a mergejoin path for a child join, prepare_sort_from_pathkeys() threw the 'could not find pathkey item to sort' error. * When deparsing a relation participating in a pushed down child join as a subquery in contrib/postgres_fdw, get_relation_column_alias_ids() threw the 'unexpected expression in subquery output' error. * When performing set_plan_references() on a local join plan generated by contrib/postgres_fdw for EvalPlanQual support for a pushed down child join, fix_join_expr() threw the 'variable not found in subplan target lists' error. To fix these, two approaches have been proposed: one by Ashutosh Bapat and one by me. While the former keeps building the child's tlist with a ConvertRowtypeExpr, the latter builds it with a whole-row Var for the child not to violate the planner assumption, and tries to fix it up later, But both approaches need more work, so refuse to generate partitionwise join paths when whole-row Vars are involved, instead. We don't need to handle ConvertRowtypeExprs in the child's tlists for now, so this commit also removes the changes to the planner. Previously, partitionwise join computed attr_needed data for each child separately, and built the child join's tlist using that data, which also required an extra step for adding PlaceHolderVars to that tlist, but it would be more efficient to build it from the parent join's tlist through the adjust_appendrel_attrs() transformation. So this commit builds that list that way, and simplifies build_joinrel_tlist() and placeholder.c as well as part of set_append_rel_size() to basically what they were before partitionwise join went in. Back-patch to PG11 where partitionwise join was introduced. Report by Rajkumar Raghuwanshi. Analysis by Ashutosh Bapat, who also provided some of regression tests. Patch by me, reviewed by Robert Haas. Discussion: https://postgr.es/m/cakcux6ktu-8teflwtquuzbyfaza83vuzurd7c1yhc-yewyy...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7cfdc77023ad50731723e85c215a4127436ed09c Modified Files -- contrib/postgres_fdw/expected/postgres_fdw.out| 71 +--- contrib/postgres_fdw/sql/postgres_fdw.sql | 14 ++- src/backend/nodes/outfuncs.c | 1 + src/backend/optimizer/path/allpaths.c | 78 ++ src/backend/optimizer/path/joinrels.c | 7 ++ src/backend/optimizer/plan/setrefs.c | 58 +- src/backend/optimizer/util/placeholder.c | 58 -- src/backend/optimizer/util/relnode.c | 125 +++--- src/include/nodes/relation.h | 8 +- src/test/regress/expected/partition_aggregate.out | 32 ++ src/test/regress/expected/partition_join.out | 57 +++--- src/test/regress/sql/partition_aggregate.sql | 5 + src/test/regress/sql/partition_join.sql | 8 +- 13 files changed, 266 insertions(+), 256 deletions(-)
pgsql: Make checksum_impl.h safe to compile with -fstrict-aliasing.
Make checksum_impl.h safe to compile with -fstrict-aliasing. In general, Postgres requires -fno-strict-aliasing with compilers that implement C99 strict aliasing rules. There's little hope of getting rid of that overall. But it seems like it would be a good idea if storage/checksum_impl.h in particular didn't depend on it, because that header is explicitly intended to be included by external programs. We don't have a lot of control over the compiler switches that an external program might use, as shown by Michael Banck's report of failure in a privately-modified version of pg_verify_checksums. Hence, switch to using a union in place of willy-nilly pointer casting inside this file. I think this makes the code a bit more readable anyway. checksum_impl.h hasn't changed since it was introduced in 9.3, so back-patch all the way. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9daff2fe69dcfaf29c7901b9e6bad285778a45c0 Modified Files -- src/include/storage/checksum_impl.h | 38 ++--- 1 file changed, 23 insertions(+), 15 deletions(-)
pgsql: Make checksum_impl.h safe to compile with -fstrict-aliasing.
Make checksum_impl.h safe to compile with -fstrict-aliasing. In general, Postgres requires -fno-strict-aliasing with compilers that implement C99 strict aliasing rules. There's little hope of getting rid of that overall. But it seems like it would be a good idea if storage/checksum_impl.h in particular didn't depend on it, because that header is explicitly intended to be included by external programs. We don't have a lot of control over the compiler switches that an external program might use, as shown by Michael Banck's report of failure in a privately-modified version of pg_verify_checksums. Hence, switch to using a union in place of willy-nilly pointer casting inside this file. I think this makes the code a bit more readable anyway. checksum_impl.h hasn't changed since it was introduced in 9.3, so back-patch all the way. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/20f9cd55dd53cd05bbf53cad38d6ad6058bbd732 Modified Files -- src/include/storage/checksum_impl.h | 38 ++--- 1 file changed, 23 insertions(+), 15 deletions(-)
pgsql: Make checksum_impl.h safe to compile with -fstrict-aliasing.
Make checksum_impl.h safe to compile with -fstrict-aliasing. In general, Postgres requires -fno-strict-aliasing with compilers that implement C99 strict aliasing rules. There's little hope of getting rid of that overall. But it seems like it would be a good idea if storage/checksum_impl.h in particular didn't depend on it, because that header is explicitly intended to be included by external programs. We don't have a lot of control over the compiler switches that an external program might use, as shown by Michael Banck's report of failure in a privately-modified version of pg_verify_checksums. Hence, switch to using a union in place of willy-nilly pointer casting inside this file. I think this makes the code a bit more readable anyway. checksum_impl.h hasn't changed since it was introduced in 9.3, so back-patch all the way. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c2dfbd18ce25c0141b681c04aa79c2e4e7cb20a7 Modified Files -- src/include/storage/checksum_impl.h | 38 ++--- 1 file changed, 23 insertions(+), 15 deletions(-)
pgsql: Make checksum_impl.h safe to compile with -fstrict-aliasing.
Make checksum_impl.h safe to compile with -fstrict-aliasing. In general, Postgres requires -fno-strict-aliasing with compilers that implement C99 strict aliasing rules. There's little hope of getting rid of that overall. But it seems like it would be a good idea if storage/checksum_impl.h in particular didn't depend on it, because that header is explicitly intended to be included by external programs. We don't have a lot of control over the compiler switches that an external program might use, as shown by Michael Banck's report of failure in a privately-modified version of pg_verify_checksums. Hence, switch to using a union in place of willy-nilly pointer casting inside this file. I think this makes the code a bit more readable anyway. checksum_impl.h hasn't changed since it was introduced in 9.3, so back-patch all the way. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/db87d3b5253f12d78dd3f8cb893c56bd4cbcfd40 Modified Files -- src/include/storage/checksum_impl.h | 38 ++--- 1 file changed, 23 insertions(+), 15 deletions(-)
pgsql: Make checksum_impl.h safe to compile with -fstrict-aliasing.
Make checksum_impl.h safe to compile with -fstrict-aliasing. In general, Postgres requires -fno-strict-aliasing with compilers that implement C99 strict aliasing rules. There's little hope of getting rid of that overall. But it seems like it would be a good idea if storage/checksum_impl.h in particular didn't depend on it, because that header is explicitly intended to be included by external programs. We don't have a lot of control over the compiler switches that an external program might use, as shown by Michael Banck's report of failure in a privately-modified version of pg_verify_checksums. Hence, switch to using a union in place of willy-nilly pointer casting inside this file. I think this makes the code a bit more readable anyway. checksum_impl.h hasn't changed since it was introduced in 9.3, so back-patch all the way. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/853af991e35a0355bbb3ac9e941ac044beb89a0e Modified Files -- src/include/storage/checksum_impl.h | 38 ++--- 1 file changed, 23 insertions(+), 15 deletions(-)
pgsql: Make checksum_impl.h safe to compile with -fstrict-aliasing.
Make checksum_impl.h safe to compile with -fstrict-aliasing. In general, Postgres requires -fno-strict-aliasing with compilers that implement C99 strict aliasing rules. There's little hope of getting rid of that overall. But it seems like it would be a good idea if storage/checksum_impl.h in particular didn't depend on it, because that header is explicitly intended to be included by external programs. We don't have a lot of control over the compiler switches that an external program might use, as shown by Michael Banck's report of failure in a privately-modified version of pg_verify_checksums. Hence, switch to using a union in place of willy-nilly pointer casting inside this file. I think this makes the code a bit more readable anyway. checksum_impl.h hasn't changed since it was introduced in 9.3, so back-patch all the way. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d6ef17ed7bba02c83408296f5fff09766e4f14dd Modified Files -- src/include/storage/checksum_impl.h | 38 ++--- 1 file changed, 23 insertions(+), 15 deletions(-)
pgsql: Make checksum_impl.h safe to compile with -fstrict-aliasing.
Make checksum_impl.h safe to compile with -fstrict-aliasing. In general, Postgres requires -fno-strict-aliasing with compilers that implement C99 strict aliasing rules. There's little hope of getting rid of that overall. But it seems like it would be a good idea if storage/checksum_impl.h in particular didn't depend on it, because that header is explicitly intended to be included by external programs. We don't have a lot of control over the compiler switches that an external program might use, as shown by Michael Banck's report of failure in a privately-modified version of pg_verify_checksums. Hence, switch to using a union in place of willy-nilly pointer casting inside this file. I think this makes the code a bit more readable anyway. checksum_impl.h hasn't changed since it was introduced in 9.3, so back-patch all the way. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8c62d9d16f014565d5f427506878812219a01604 Modified Files -- src/include/storage/checksum_impl.h | 38 ++--- 1 file changed, 23 insertions(+), 15 deletions(-)
pgsql: Split contrib/cube platform-depended checks into separate test
Split contrib/cube platform-depended checks into separate test We're currently maintaining two outputs for cube regression test. But that appears to be unsuitable, because these outputs are different in out few checks involving scientific notation. So, split checks involving scientific notation into separate test, making contrib/cube easier to maintain. Backpatch to all supported versions in order to make further backpatching easier. Discussion: https://postgr.es/m/CAPpHfdvJgWjxHsJTtT%2Bo1tz3OR8EFHcLQjhp-d3%2BUcmJLh-fQA%40mail.gmail.com Author: Alexander Korotkov Backpatch-through: 9.3 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/41180978b4039aee5128f0e339d1a139ad2eb68e Modified Files -- contrib/cube/Makefile|2 +- contrib/cube/expected/cube.out | 102 --- contrib/cube/expected/cube_1.out | 1409 -- contrib/cube/expected/cube_2.out | 1409 -- contrib/cube/expected/cube_3.out | 1409 -- contrib/cube/expected/cube_sci.out | 106 +++ contrib/cube/expected/cube_sci_1.out | 106 +++ contrib/cube/expected/cube_sci_2.out | 106 +++ contrib/cube/expected/cube_sci_3.out | 106 +++ contrib/cube/sql/cube.sql| 17 - contrib/cube/sql/cube_sci.sql| 22 + 11 files changed, 447 insertions(+), 4347 deletions(-)
pgsql: Split contrib/cube platform-depended checks into separate test
Split contrib/cube platform-depended checks into separate test We're currently maintaining two outputs for cube regression test. But that appears to be unsuitable, because these outputs are different in out few checks involving scientific notation. So, split checks involving scientific notation into separate test, making contrib/cube easier to maintain. Backpatch to all supported versions in order to make further backpatching easier. Discussion: https://postgr.es/m/CAPpHfdvJgWjxHsJTtT%2Bo1tz3OR8EFHcLQjhp-d3%2BUcmJLh-fQA%40mail.gmail.com Author: Alexander Korotkov Backpatch-through: 9.3 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/26cbd23259403b27641d6c5a2798052aa3854e01 Modified Files -- contrib/cube/Makefile|2 +- contrib/cube/expected/cube.out | 102 --- contrib/cube/expected/cube_1.out | 1409 -- contrib/cube/expected/cube_2.out | 1409 -- contrib/cube/expected/cube_3.out | 1409 -- contrib/cube/expected/cube_sci.out | 106 +++ contrib/cube/expected/cube_sci_1.out | 106 +++ contrib/cube/expected/cube_sci_2.out | 106 +++ contrib/cube/expected/cube_sci_3.out | 106 +++ contrib/cube/sql/cube.sql| 17 - contrib/cube/sql/cube_sci.sql| 22 + 11 files changed, 447 insertions(+), 4347 deletions(-)
pgsql: Enforce cube dimension limit in all cube construction functions
Enforce cube dimension limit in all cube construction functions contrib/cube has a limit to 100 dimensions for cube datatype. However, it's not enforced everywhere, and one can actually construct cube with more than 100 dimensions having then trouble with dump/restore. This commit add checks for dimensions limit in all functions responsible for cube construction. Backpatch to all supported versions. Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87va7uybt4.fsf%40news-spur.riddles.org.uk Author: Andrey Borodin with small additions by me Review: Tom Lane Backpatch-through: 9.3 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b187dae9d0416423b206ec25941353561a688c9b Modified Files -- contrib/cube/cube.c| 34 ++ contrib/cube/expected/cube.out | 40 contrib/cube/sql/cube.sql | 20 +++- 3 files changed, 93 insertions(+), 1 deletion(-)
pgsql: Split contrib/cube platform-depended checks into separate test
Split contrib/cube platform-depended checks into separate test We're currently maintaining two outputs for cube regression test. But that appears to be unsuitable, because these outputs are different in out few checks involving scientific notation. So, split checks involving scientific notation into separate test, making contrib/cube easier to maintain. Backpatch to all supported versions in order to make further backpatching easier. Discussion: https://postgr.es/m/CAPpHfdvJgWjxHsJTtT%2Bo1tz3OR8EFHcLQjhp-d3%2BUcmJLh-fQA%40mail.gmail.com Author: Alexander Korotkov Backpatch-through: 9.3 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5d6a1ee9a50f60324aa177fc0f64b7e66e479fb4 Modified Files -- contrib/cube/Makefile|2 +- contrib/cube/expected/cube.out | 102 --- contrib/cube/expected/cube_1.out | 1128 -- contrib/cube/expected/cube_2.out | 1128 -- contrib/cube/expected/cube_3.out | 1128 -- contrib/cube/expected/cube_sci.out | 106 contrib/cube/expected/cube_sci_1.out | 106 contrib/cube/expected/cube_sci_2.out | 106 contrib/cube/expected/cube_sci_3.out | 106 contrib/cube/sql/cube.sql| 17 - contrib/cube/sql/cube_sci.sql| 22 + 11 files changed, 447 insertions(+), 3504 deletions(-)
pgsql: Enforce cube dimension limit in all cube construction functions
Enforce cube dimension limit in all cube construction functions contrib/cube has a limit to 100 dimensions for cube datatype. However, it's not enforced everywhere, and one can actually construct cube with more than 100 dimensions having then trouble with dump/restore. This commit add checks for dimensions limit in all functions responsible for cube construction. Backpatch to all supported versions. Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87va7uybt4.fsf%40news-spur.riddles.org.uk Author: Andrey Borodin with small additions by me Review: Tom Lane Backpatch-through: 9.3 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9f3ade1a6f62dd0315aa14b615666e0d54054763 Modified Files -- contrib/cube/cube.c| 34 ++ contrib/cube/expected/cube.out | 40 contrib/cube/sql/cube.sql | 18 +- 3 files changed, 91 insertions(+), 1 deletion(-)
pgsql: Enforce cube dimension limit in all cube construction functions
Enforce cube dimension limit in all cube construction functions contrib/cube has a limit to 100 dimensions for cube datatype. However, it's not enforced everywhere, and one can actually construct cube with more than 100 dimensions having then trouble with dump/restore. This commit add checks for dimensions limit in all functions responsible for cube construction. Backpatch to all supported versions. Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87va7uybt4.fsf%40news-spur.riddles.org.uk Author: Andrey Borodin with small additions by me Review: Tom Lane Backpatch-through: 9.3 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7cea5e6ebfb3814d977c62bbe91775e0858acb50 Modified Files -- contrib/cube/cube.c| 34 ++ contrib/cube/expected/cube.out | 40 contrib/cube/sql/cube.sql | 20 +++- 3 files changed, 93 insertions(+), 1 deletion(-)
pgsql: Enforce cube dimension limit in all cube construction functions
Enforce cube dimension limit in all cube construction functions contrib/cube has a limit to 100 dimensions for cube datatype. However, it's not enforced everywhere, and one can actually construct cube with more than 100 dimensions having then trouble with dump/restore. This commit add checks for dimensions limit in all functions responsible for cube construction. Backpatch to all supported versions. Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87va7uybt4.fsf%40news-spur.riddles.org.uk Author: Andrey Borodin with small additions by me Review: Tom Lane Backpatch-through: 9.3 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5fed7b24aed50a50e2e922de2bcc51458a067210 Modified Files -- contrib/cube/cube.c| 34 ++ contrib/cube/expected/cube.out | 40 contrib/cube/sql/cube.sql | 20 +++- 3 files changed, 93 insertions(+), 1 deletion(-)
pgsql: Split contrib/cube platform-depended checks into separate test
Split contrib/cube platform-depended checks into separate test We're currently maintaining two outputs for cube regression test. But that appears to be unsuitable, because these outputs are different in out few checks involving scientific notation. So, split checks involving scientific notation into separate test, making contrib/cube easier to maintain. Backpatch to all supported versions in order to make further backpatching easier. Discussion: https://postgr.es/m/CAPpHfdvJgWjxHsJTtT%2Bo1tz3OR8EFHcLQjhp-d3%2BUcmJLh-fQA%40mail.gmail.com Author: Alexander Korotkov Backpatch-through: 9.3 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/df85f8ecea535eee425ea66b3ecf852739e54cea Modified Files -- contrib/cube/Makefile|2 +- contrib/cube/expected/cube.out | 102 -- contrib/cube/expected/cube_1.out | 1783 -- contrib/cube/expected/cube_2.out | 1783 -- contrib/cube/expected/cube_3.out | 1783 -- contrib/cube/expected/cube_sci.out | 106 ++ contrib/cube/expected/cube_sci_1.out | 106 ++ contrib/cube/expected/cube_sci_2.out | 106 ++ contrib/cube/expected/cube_sci_3.out | 106 ++ contrib/cube/sql/cube.sql| 17 - contrib/cube/sql/cube_sci.sql| 22 + 11 files changed, 447 insertions(+), 5469 deletions(-)
pgsql: Enforce cube dimension limit in all cube construction functions
Enforce cube dimension limit in all cube construction functions contrib/cube has a limit to 100 dimensions for cube datatype. However, it's not enforced everywhere, and one can actually construct cube with more than 100 dimensions having then trouble with dump/restore. This commit add checks for dimensions limit in all functions responsible for cube construction. Backpatch to all supported versions. Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87va7uybt4.fsf%40news-spur.riddles.org.uk Author: Andrey Borodin with small additions by me Review: Tom Lane Backpatch-through: 9.3 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/29e07cd224717fd11be7071166d9f08f8b44f1f2 Modified Files -- contrib/cube/cube.c| 34 ++ contrib/cube/expected/cube.out | 40 contrib/cube/sql/cube.sql | 20 +++- 3 files changed, 93 insertions(+), 1 deletion(-)
pgsql: Split contrib/cube platform-depended checks into separate test
Split contrib/cube platform-depended checks into separate test We're currently maintaining two outputs for cube regression test. But that appears to be unsuitable, because these outputs are different in out few checks involving scientific notation. So, split checks involving scientific notation into separate test, making contrib/cube easier to maintain. Backpatch to all supported versions in order to make further backpatching easier. Discussion: https://postgr.es/m/CAPpHfdvJgWjxHsJTtT%2Bo1tz3OR8EFHcLQjhp-d3%2BUcmJLh-fQA%40mail.gmail.com Author: Alexander Korotkov Backpatch-through: 9.3 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4ffb7c7b3c0a6bb291aff23b0acd94012cde6a48 Modified Files -- contrib/cube/Makefile|2 +- contrib/cube/expected/cube.out | 102 -- contrib/cube/expected/cube_2.out | 1820 -- contrib/cube/expected/cube_sci.out | 106 ++ contrib/cube/expected/cube_sci_1.out | 106 ++ contrib/cube/sql/cube.sql| 17 - contrib/cube/sql/cube_sci.sql| 22 + 7 files changed, 235 insertions(+), 1940 deletions(-)
pgsql: Split contrib/cube platform-depended checks into separate test
Split contrib/cube platform-depended checks into separate test We're currently maintaining two outputs for cube regression test. But that appears to be unsuitable, because these outputs are different in out few checks involving scientific notation. So, split checks involving scientific notation into separate test, making contrib/cube easier to maintain. Backpatch to all supported versions in order to make further backpatching easier. Discussion: https://postgr.es/m/CAPpHfdvJgWjxHsJTtT%2Bo1tz3OR8EFHcLQjhp-d3%2BUcmJLh-fQA%40mail.gmail.com Author: Alexander Korotkov Backpatch-through: 9.3 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1668186eb37851df41c9ff4b9ba9b4f71ce4f348 Modified Files -- contrib/cube/Makefile|2 +- contrib/cube/expected/cube.out | 102 -- contrib/cube/expected/cube_2.out | 2006 -- contrib/cube/expected/cube_sci.out | 106 ++ contrib/cube/expected/cube_sci_1.out | 106 ++ contrib/cube/sql/cube.sql| 17 - contrib/cube/sql/cube_sci.sql| 22 + 7 files changed, 235 insertions(+), 2126 deletions(-)
pgsql: Enforce cube dimension limit in all cube construction functions
Enforce cube dimension limit in all cube construction functions contrib/cube has a limit to 100 dimensions for cube datatype. However, it's not enforced everywhere, and one can actually construct cube with more than 100 dimensions having then trouble with dump/restore. This commit add checks for dimensions limit in all functions responsible for cube construction. Backpatch to all supported versions. Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87va7uybt4.fsf%40news-spur.riddles.org.uk Author: Andrey Borodin with small additions by me Review: Tom Lane Backpatch-through: 9.3 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/36343e59b51165da542943d2043878737fbe910b Modified Files -- contrib/cube/cube.c| 34 ++ contrib/cube/expected/cube.out | 40 contrib/cube/sql/cube.sql | 20 +++- 3 files changed, 93 insertions(+), 1 deletion(-)
pgsql: Enforce cube dimension limit in all cube construction functions
Enforce cube dimension limit in all cube construction functions contrib/cube has a limit to 100 dimensions for cube datatype. However, it's not enforced everywhere, and one can actually construct cube with more than 100 dimensions having then trouble with dump/restore. This commit add checks for dimensions limit in all functions responsible for cube construction. Backpatch to all supported versions. Reported-by: Andrew Gierth Discussion: https://postgr.es/m/87va7uybt4.fsf%40news-spur.riddles.org.uk Author: Andrey Borodin with small additions by me Review: Tom Lane Backpatch-through: 9.3 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f919c165ebdc2f85e4584e959e002705a5a0a774 Modified Files -- contrib/cube/cube.c| 34 ++ contrib/cube/expected/cube.out | 40 contrib/cube/sql/cube.sql | 20 +++- 3 files changed, 93 insertions(+), 1 deletion(-)
pgsql: Split contrib/cube platform-depended checks into separate test
Split contrib/cube platform-depended checks into separate test We're currently maintaining two outputs for cube regression test. But that appears to be unsuitable, because these outputs are different in out few checks involving scientific notation. So, split checks involving scientific notation into separate test, making contrib/cube easier to maintain. Backpatch to all supported versions in order to make further backpatching easier. Discussion: https://postgr.es/m/CAPpHfdvJgWjxHsJTtT%2Bo1tz3OR8EFHcLQjhp-d3%2BUcmJLh-fQA%40mail.gmail.com Author: Alexander Korotkov Backpatch-through: 9.3 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/38970ce862b906d3b6e3745bff8c75edad378de3 Modified Files -- contrib/cube/Makefile|2 +- contrib/cube/expected/cube.out | 102 -- contrib/cube/expected/cube_2.out | 2006 -- contrib/cube/expected/cube_sci.out | 106 ++ contrib/cube/expected/cube_sci_1.out | 106 ++ contrib/cube/sql/cube.sql| 17 - contrib/cube/sql/cube_sci.sql| 22 + 7 files changed, 235 insertions(+), 2126 deletions(-)
pgsql: Code review for pg_verify_checksums.c.
Code review for pg_verify_checksums.c. Use postgres_fe.h, since this is frontend code. Pretend that we've heard of project style guidelines for, eg, #include order. Use BlockNumber not int arithmetic for block numbers, to avoid misbehavior with relations exceeding 2^31 blocks. Avoid an unnecessary strict-aliasing warning (per report from Michael Banck). Const-ify assorted stuff. Avoid scribbling on the output of readdir() -- perhaps that's safe in practice, but POSIX forbids it, and this code has so far earned exactly zero credibility portability-wise. Editorialize on an ambiguously-worded message. I did not touch the problem of the "buf" local variable being possibly insufficiently aligned; that's not specific to this code, and seems like it should be fixed as part of a different, larger patch. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d9c366f9e8017306201fe12d27212d8720395c04 Modified Files -- src/bin/pg_verify_checksums/pg_verify_checksums.c | 47 +++ 1 file changed, 23 insertions(+), 24 deletions(-)
pgsql: Code review for pg_verify_checksums.c.
Code review for pg_verify_checksums.c. Use postgres_fe.h, since this is frontend code. Pretend that we've heard of project style guidelines for, eg, #include order. Use BlockNumber not int arithmetic for block numbers, to avoid misbehavior with relations exceeding 2^31 blocks. Avoid an unnecessary strict-aliasing warning (per report from Michael Banck). Const-ify assorted stuff. Avoid scribbling on the output of readdir() -- perhaps that's safe in practice, but POSIX forbids it, and this code has so far earned exactly zero credibility portability-wise. Editorialize on an ambiguously-worded message. I did not touch the problem of the "buf" local variable being possibly insufficiently aligned; that's not specific to this code, and seems like it should be fixed as part of a different, larger patch. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d787af7badfe8c4c9afb7f0af9958a69b723a212 Modified Files -- src/bin/pg_verify_checksums/pg_verify_checksums.c | 47 +++ 1 file changed, 23 insertions(+), 24 deletions(-)
pgsql: Ensure correct minimum consistent point on standbys
Ensure correct minimum consistent point on standbys Startup process has improved its calculation of incorrect minimum consistent point in 8d68ee6, which ensures that all WAL available gets replayed when doing crash recovery, and has introduced an incorrect calculation of the minimum recovery point for non-startup processes, which can cause incorrect page references on a standby when for example the background writer flushed a couple of pages on-disk but was not updating the control file to let a subsequent crash recovery replay to where it should have. The only case where this has been reported to be a problem is when a standby needs to calculate the latest removed xid when replaying a btree deletion record, so one would need connections on a standby that happen just after recovery has thought it reached a consistent point. Using a background worker which is started after the consistent point is reached would be the easiest way to get into problems if it connects to a database. Having clients which attempt to connect periodically could also be a problem, but the odds of seeing this problem are much lower. The fix used is pretty simple, as the idea is to give access to the minimum recovery point written in the control file to non-startup processes so as they use a reference, while the startup process still initializes its own references of the minimum consistent point so as the original problem with incorrect page references happening post-promotion with a crash do not show up. Reported-by: Alexander Kukushkin Diagnosed-by: Alexander Kukushkin Author: Michael Paquier Reviewed-by: Kyotaro Horiguchi, Alexander Kukushkin Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.3 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c34f8078aa354a9c352b6db488ca1d5aac39560c Modified Files -- src/backend/access/transam/xlog.c | 31 +-- 1 file changed, 25 insertions(+), 6 deletions(-)
pgsql: Ensure correct minimum consistent point on standbys
Ensure correct minimum consistent point on standbys Startup process has improved its calculation of incorrect minimum consistent point in 8d68ee6, which ensures that all WAL available gets replayed when doing crash recovery, and has introduced an incorrect calculation of the minimum recovery point for non-startup processes, which can cause incorrect page references on a standby when for example the background writer flushed a couple of pages on-disk but was not updating the control file to let a subsequent crash recovery replay to where it should have. The only case where this has been reported to be a problem is when a standby needs to calculate the latest removed xid when replaying a btree deletion record, so one would need connections on a standby that happen just after recovery has thought it reached a consistent point. Using a background worker which is started after the consistent point is reached would be the easiest way to get into problems if it connects to a database. Having clients which attempt to connect periodically could also be a problem, but the odds of seeing this problem are much lower. The fix used is pretty simple, as the idea is to give access to the minimum recovery point written in the control file to non-startup processes so as they use a reference, while the startup process still initializes its own references of the minimum consistent point so as the original problem with incorrect page references happening post-promotion with a crash do not show up. Reported-by: Alexander Kukushkin Diagnosed-by: Alexander Kukushkin Author: Michael Paquier Reviewed-by: Kyotaro Horiguchi, Alexander Kukushkin Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.3 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f3520ff6fbf1e213069ec6ee0d02d2a9bdbc19de Modified Files -- src/backend/access/transam/xlog.c | 31 +-- 1 file changed, 25 insertions(+), 6 deletions(-)
pgsql: Ensure correct minimum consistent point on standbys
Ensure correct minimum consistent point on standbys Startup process has improved its calculation of incorrect minimum consistent point in 8d68ee6, which ensures that all WAL available gets replayed when doing crash recovery, and has introduced an incorrect calculation of the minimum recovery point for non-startup processes, which can cause incorrect page references on a standby when for example the background writer flushed a couple of pages on-disk but was not updating the control file to let a subsequent crash recovery replay to where it should have. The only case where this has been reported to be a problem is when a standby needs to calculate the latest removed xid when replaying a btree deletion record, so one would need connections on a standby that happen just after recovery has thought it reached a consistent point. Using a background worker which is started after the consistent point is reached would be the easiest way to get into problems if it connects to a database. Having clients which attempt to connect periodically could also be a problem, but the odds of seeing this problem are much lower. The fix used is pretty simple, as the idea is to give access to the minimum recovery point written in the control file to non-startup processes so as they use a reference, while the startup process still initializes its own references of the minimum consistent point so as the original problem with incorrect page references happening post-promotion with a crash do not show up. Reported-by: Alexander Kukushkin Diagnosed-by: Alexander Kukushkin Author: Michael Paquier Reviewed-by: Kyotaro Horiguchi, Alexander Kukushkin Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.3 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d9638a326f722af7e5c7e92995ed0e22ace670a3 Modified Files -- src/backend/access/transam/xlog.c | 31 +-- 1 file changed, 25 insertions(+), 6 deletions(-)
pgsql: Ensure correct minimum consistent point on standbys
Ensure correct minimum consistent point on standbys Startup process has improved its calculation of incorrect minimum consistent point in 8d68ee6, which ensures that all WAL available gets replayed when doing crash recovery, and has introduced an incorrect calculation of the minimum recovery point for non-startup processes, which can cause incorrect page references on a standby when for example the background writer flushed a couple of pages on-disk but was not updating the control file to let a subsequent crash recovery replay to where it should have. The only case where this has been reported to be a problem is when a standby needs to calculate the latest removed xid when replaying a btree deletion record, so one would need connections on a standby that happen just after recovery has thought it reached a consistent point. Using a background worker which is started after the consistent point is reached would be the easiest way to get into problems if it connects to a database. Having clients which attempt to connect periodically could also be a problem, but the odds of seeing this problem are much lower. The fix used is pretty simple, as the idea is to give access to the minimum recovery point written in the control file to non-startup processes so as they use a reference, while the startup process still initializes its own references of the minimum consistent point so as the original problem with incorrect page references happening post-promotion with a crash do not show up. Reported-by: Alexander Kukushkin Diagnosed-by: Alexander Kukushkin Author: Michael Paquier Reviewed-by: Kyotaro Horiguchi, Alexander Kukushkin Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.3 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2c8cff5dd60b372654eda4dba72b1cea2e91f0f0 Modified Files -- src/backend/access/transam/xlog.c | 31 +-- 1 file changed, 25 insertions(+), 6 deletions(-)
pgsql: Ensure correct minimum consistent point on standbys
Ensure correct minimum consistent point on standbys Startup process has improved its calculation of incorrect minimum consistent point in 8d68ee6, which ensures that all WAL available gets replayed when doing crash recovery, and has introduced an incorrect calculation of the minimum recovery point for non-startup processes, which can cause incorrect page references on a standby when for example the background writer flushed a couple of pages on-disk but was not updating the control file to let a subsequent crash recovery replay to where it should have. The only case where this has been reported to be a problem is when a standby needs to calculate the latest removed xid when replaying a btree deletion record, so one would need connections on a standby that happen just after recovery has thought it reached a consistent point. Using a background worker which is started after the consistent point is reached would be the easiest way to get into problems if it connects to a database. Having clients which attempt to connect periodically could also be a problem, but the odds of seeing this problem are much lower. The fix used is pretty simple, as the idea is to give access to the minimum recovery point written in the control file to non-startup processes so as they use a reference, while the startup process still initializes its own references of the minimum consistent point so as the original problem with incorrect page references happening post-promotion with a crash do not show up. Reported-by: Alexander Kukushkin Diagnosed-by: Alexander Kukushkin Author: Michael Paquier Reviewed-by: Kyotaro Horiguchi, Alexander Kukushkin Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.3 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c186ba135ecafe987842920829629ef466ce6ce1 Modified Files -- src/backend/access/transam/xlog.c | 31 +-- 1 file changed, 25 insertions(+), 6 deletions(-)
pgsql: Ensure correct minimum consistent point on standbys
Ensure correct minimum consistent point on standbys Startup process has improved its calculation of incorrect minimum consistent point in 8d68ee6, which ensures that all WAL available gets replayed when doing crash recovery, and has introduced an incorrect calculation of the minimum recovery point for non-startup processes, which can cause incorrect page references on a standby when for example the background writer flushed a couple of pages on-disk but was not updating the control file to let a subsequent crash recovery replay to where it should have. The only case where this has been reported to be a problem is when a standby needs to calculate the latest removed xid when replaying a btree deletion record, so one would need connections on a standby that happen just after recovery has thought it reached a consistent point. Using a background worker which is started after the consistent point is reached would be the easiest way to get into problems if it connects to a database. Having clients which attempt to connect periodically could also be a problem, but the odds of seeing this problem are much lower. The fix used is pretty simple, as the idea is to give access to the minimum recovery point written in the control file to non-startup processes so as they use a reference, while the startup process still initializes its own references of the minimum consistent point so as the original problem with incorrect page references happening post-promotion with a crash do not show up. Reported-by: Alexander Kukushkin Diagnosed-by: Alexander Kukushkin Author: Michael Paquier Reviewed-by: Kyotaro Horiguchi, Alexander Kukushkin Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.3 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/65f39408ee71736dedf20c4a8eb85faf2fa2054d Modified Files -- src/backend/access/transam/xlog.c | 31 +-- 1 file changed, 25 insertions(+), 6 deletions(-)
pgsql: Ensure correct minimum consistent point on standbys
Ensure correct minimum consistent point on standbys Startup process has improved its calculation of incorrect minimum consistent point in 8d68ee6, which ensures that all WAL available gets replayed when doing crash recovery, and has introduced an incorrect calculation of the minimum recovery point for non-startup processes, which can cause incorrect page references on a standby when for example the background writer flushed a couple of pages on-disk but was not updating the control file to let a subsequent crash recovery replay to where it should have. The only case where this has been reported to be a problem is when a standby needs to calculate the latest removed xid when replaying a btree deletion record, so one would need connections on a standby that happen just after recovery has thought it reached a consistent point. Using a background worker which is started after the consistent point is reached would be the easiest way to get into problems if it connects to a database. Having clients which attempt to connect periodically could also be a problem, but the odds of seeing this problem are much lower. The fix used is pretty simple, as the idea is to give access to the minimum recovery point written in the control file to non-startup processes so as they use a reference, while the startup process still initializes its own references of the minimum consistent point so as the original problem with incorrect page references happening post-promotion with a crash do not show up. Reported-by: Alexander Kukushkin Diagnosed-by: Alexander Kukushkin Author: Michael Paquier Reviewed-by: Kyotaro Horiguchi, Alexander Kukushkin Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.3 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4a9a5bb3fd2a6aafda1e3bd8ef25c1fb004f5c87 Modified Files -- src/backend/access/transam/xlog.c | 31 +-- 1 file changed, 25 insertions(+), 6 deletions(-)
pgsql: Fix psql's \dC command to annotate I/O conversion casts as such.
Fix psql's \dC command to annotate I/O conversion casts as such. A cast declared WITH INOUT was described as '(binary coercible)', which seems pretty inaccurate; let's print '(with inout)' instead. Per complaint from Jean-Pierre Pelletier. This definitely seems like a bug fix, but given that it's been wrong since 8.4 and nobody complained before, I'm hesitant to back-patch a behavior change into stable branches. It doesn't seem too late for v11 though. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/115bf1e79af0114c18d7d5675f4ba7e8bd6e11e9 Modified Files -- src/bin/psql/describe.c | 56 + 1 file changed, 38 insertions(+), 18 deletions(-)
pgsql: Fix psql's \dC command to annotate I/O conversion casts as such.
Fix psql's \dC command to annotate I/O conversion casts as such. A cast declared WITH INOUT was described as '(binary coercible)', which seems pretty inaccurate; let's print '(with inout)' instead. Per complaint from Jean-Pierre Pelletier. This definitely seems like a bug fix, but given that it's been wrong since 8.4 and nobody complained before, I'm hesitant to back-patch a behavior change into stable branches. It doesn't seem too late for v11 though. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ed9c336b0f6bcf08e7b6bbe7080fdb63640a680e Modified Files -- src/bin/psql/describe.c | 56 + 1 file changed, 38 insertions(+), 18 deletions(-)
pgsql: Fix 8a934d677 for libc++ and make more include order resistant.
Fix 8a934d677 for libc++ and make more include order resistant. The previous definition was used in C++ mode, which causes problems when using clang with libc++ (rather than libstdc++), due to bugs therein. So just avoid in C++ mode. A second problem is that depending on include order and implicit includes the previous definition did not guarantee that the current hack was effective by the time isinf was used, fix that by forcing math.h to be included. This can cause clang using builds, or gcc using ones with JIT enabled, to slow down noticably. It's likely that we at some point want a better solution for the performance problem, but while it's there it should better work. Reported-By: Steven Winfield Bug: #15270 Discussion: https://postgr.es/m/[email protected] Author: Andres Freund Backpatch: 11, like the previous commit. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5758685c9f1a51b0a77ae8f415a57670941f2c4b Modified Files -- src/include/port.h | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-)
pgsql: Fix 8a934d677 for libc++ and make more include order resistant.
Fix 8a934d677 for libc++ and make more include order resistant. The previous definition was used in C++ mode, which causes problems when using clang with libc++ (rather than libstdc++), due to bugs therein. So just avoid in C++ mode. A second problem is that depending on include order and implicit includes the previous definition did not guarantee that the current hack was effective by the time isinf was used, fix that by forcing math.h to be included. This can cause clang using builds, or gcc using ones with JIT enabled, to slow down noticably. It's likely that we at some point want a better solution for the performance problem, but while it's there it should better work. Reported-By: Steven Winfield Bug: #15270 Discussion: https://postgr.es/m/[email protected] Author: Andres Freund Backpatch: 11, like the previous commit. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1f349aa7d9a6633e87db071390c73a39ac279ba4 Modified Files -- src/include/port.h | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-)
pgsql: Ignore server-side delays when enforcing wal_sender_timeout.
Ignore server-side delays when enforcing wal_sender_timeout. Healthy clients of servers having poor I/O performance, such as buildfarm members hamster and tern, saw unexpected timeouts. That disagreed with documentation. This fix adds one gettimeofday() call whenever ProcessRepliesIfAny() finds no client reply messages. Back-patch to 9.4; the bug's symptom is rare and mild, and the code all moved between 9.3 and 9.4. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ee0ab275408f8fc10eedd7fb8c767cdbad0cb57b Modified Files -- src/backend/replication/walsender.c | 64 + 1 file changed, 36 insertions(+), 28 deletions(-)
pgsql: Ignore server-side delays when enforcing wal_sender_timeout.
Ignore server-side delays when enforcing wal_sender_timeout. Healthy clients of servers having poor I/O performance, such as buildfarm members hamster and tern, saw unexpected timeouts. That disagreed with documentation. This fix adds one gettimeofday() call whenever ProcessRepliesIfAny() finds no client reply messages. Back-patch to 9.4; the bug's symptom is rare and mild, and the code all moved between 9.3 and 9.4. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ab0ed6153a58294143d6d66ec5f3471477c59d57 Modified Files -- src/backend/replication/walsender.c | 64 + 1 file changed, 36 insertions(+), 28 deletions(-)
pgsql: Ignore server-side delays when enforcing wal_sender_timeout.
Ignore server-side delays when enforcing wal_sender_timeout. Healthy clients of servers having poor I/O performance, such as buildfarm members hamster and tern, saw unexpected timeouts. That disagreed with documentation. This fix adds one gettimeofday() call whenever ProcessRepliesIfAny() finds no client reply messages. Back-patch to 9.4; the bug's symptom is rare and mild, and the code all moved between 9.3 and 9.4. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/20cd88857b3a60d40cf019872cf8a5d40888e3ae Modified Files -- src/backend/replication/walsender.c | 64 + 1 file changed, 36 insertions(+), 28 deletions(-)
pgsql: Ignore server-side delays when enforcing wal_sender_timeout.
Ignore server-side delays when enforcing wal_sender_timeout. Healthy clients of servers having poor I/O performance, such as buildfarm members hamster and tern, saw unexpected timeouts. That disagreed with documentation. This fix adds one gettimeofday() call whenever ProcessRepliesIfAny() finds no client reply messages. Back-patch to 9.4; the bug's symptom is rare and mild, and the code all moved between 9.3 and 9.4. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1664c8b300e345158b007eba2c6879e7bde74cc8 Modified Files -- src/backend/replication/walsender.c | 64 + 1 file changed, 36 insertions(+), 28 deletions(-)
pgsql: Ignore server-side delays when enforcing wal_sender_timeout.
Ignore server-side delays when enforcing wal_sender_timeout. Healthy clients of servers having poor I/O performance, such as buildfarm members hamster and tern, saw unexpected timeouts. That disagreed with documentation. This fix adds one gettimeofday() call whenever ProcessRepliesIfAny() finds no client reply messages. Back-patch to 9.4; the bug's symptom is rare and mild, and the code all moved between 9.3 and 9.4. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/081e4104a4317709c1adf0fab42a1546ebf8d6b2 Modified Files -- src/backend/replication/walsender.c | 64 + 1 file changed, 36 insertions(+), 28 deletions(-)
pgsql: Ignore server-side delays when enforcing wal_sender_timeout.
Ignore server-side delays when enforcing wal_sender_timeout. Healthy clients of servers having poor I/O performance, such as buildfarm members hamster and tern, saw unexpected timeouts. That disagreed with documentation. This fix adds one gettimeofday() call whenever ProcessRepliesIfAny() finds no client reply messages. Back-patch to 9.4; the bug's symptom is rare and mild, and the code all moved between 9.3 and 9.4. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e3eca937c7432bdbb72cb3033585512cd4438806 Modified Files -- src/backend/replication/walsender.c | 64 + 1 file changed, 36 insertions(+), 28 deletions(-)
