pgsql: Fix out of date comment
Fix out of date comment Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3f16cb505d1d734674da2a2cbf2104ceae22f9b4 Modified Files -- src/backend/postmaster/postmaster.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Remove -o option to postmaster
Remove -o option to postmaster This option was declared obsolete many years ago. Reviewed-By: Tom Lane Discussion: https://postgr.es/m/CABUevEyOE=9CQwZm2j=vwp5+6olcsoxn9pbjk8gyrdktzmf...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d2e4bf688e16f95d180b68b7cbb7881b12434dba Modified Files -- doc/src/sgml/ref/postgres-ref.sgml | 26 --- src/backend/main/main.c | 1 - src/backend/postmaster/postmaster.c | 66 +++-- src/backend/tcop/postgres.c | 6 +--- 4 files changed, 6 insertions(+), 93 deletions(-)
Re: pgsql: Declare assorted array functions using anycompatible not anyelem
On 11/9/20 5:41 PM, Tom Lane wrote:
>
> What I have in mind to apply to 9.5 through 13 is per attached.
> You could either redefine the aggregate similarly in 9.2-9.4,
> or just drop it. I doubt the latter leads to any interesting
> loss of coverage for xversion upgrade, as there's plenty of other
> user-defined aggregates in the regression database.
You also need to modify first_el_agg_any.
Here's what I have working on crake::
if ($oversion le 'REL9_4_STABLE')
{
# this is to be fixed in 9.5 and later
$prstmt = join(';',
'drop aggregate if exists
public.array_cat_accum(anyarray)',
'CREATE AGGREGATE array_larger_accum
(anyarray) ' .
' ( ' .
' sfunc = array_larger, ' .
' stype = anyarray, ' .
' initcond = $${}$$ ' .
' ) ' );
system( "$other_branch/inst/bin/psql -X -e "
. " -c '" . $prstmt . "' "
. "regression "
. ">> '$upgrade_loc/$oversion-copy.log' 2>&1");
return if $?;
}
# drop this branch when upstream is renovated
else
{
$prstmt = join(';',
'drop aggregate if exists
public.array_cat_accum(anyarray)',
'drop aggregate if exists
public.first_el_agg_any(anyelement)');
system( "$other_branch/inst/bin/psql -X -e "
. " -c '$prstmt' "
. "regression "
. ">> '$upgrade_loc/$oversion-copy.log' 2>&1");
return if $?;
}
When you fix the live branches I'll delete the "else" branch and push
the change to the git repo.
cheers
andrew
pgsql: pg_rewind: Fix thinko in parsing target WAL.
pg_rewind: Fix thinko in parsing target WAL. It's entirely possible to see WAL for a relation that doesn't exist in the target anymore. That happens when the relation was dropped later. The refactoring in commit eb00f1d4b broke that case, by sanity-checking the file type in the target before checking the flag forwhether it exists there at all. I noticed this during manual testing. Modify the 001_basic.pl test so that it covers this case. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/72d172743e52f31bb874e3bbc07544b30bf0bb51 Modified Files -- src/bin/pg_rewind/filemap.c | 21 - src/bin/pg_rewind/t/001_basic.pl | 1 + 2 files changed, 13 insertions(+), 9 deletions(-)
Re: pgsql: Declare assorted array functions using anycompatible not anyelem
Andrew Dunstan writes: > On 11/9/20 5:41 PM, Tom Lane wrote: >> What I have in mind to apply to 9.5 through 13 is per attached. > You also need to modify first_el_agg_any. ... doh. That one is a little messier because there's no equally useful substitute function. What I'm inclined to do for that is to add a SQL-language wrapper to reproduce the old signature for array_append. As attached. (I'm keeping this separate from the other patch, since this doesn't go back as far.) > Here's what I have working on crake:: OK. regards, tom lane diff --git a/src/test/regress/expected/polymorphism.out b/src/test/regress/expected/polymorphism.out index 2c3bb0a60b..628a39612a 100644 --- a/src/test/regress/expected/polymorphism.out +++ b/src/test/regress/expected/polymorphism.out @@ -786,16 +786,18 @@ create aggregate build_group(int8, integer) ( STYPE = int8[] ); -- check proper resolution of data types for polymorphic transfn/finalfn -create function first_el(anycompatiblearray) returns anycompatible as +create function first_el_transfn(anyarray, anyelement) returns anyarray as +'select $1 || $2' language sql immutable; +create function first_el(anyarray) returns anyelement as 'select $1[1]' language sql strict immutable; create aggregate first_el_agg_f8(float8) ( SFUNC = array_append, STYPE = float8[], FINALFUNC = first_el ); -create aggregate first_el_agg_any(anycompatible) ( - SFUNC = array_append, - STYPE = anycompatiblearray, +create aggregate first_el_agg_any(anyelement) ( + SFUNC = first_el_transfn, + STYPE = anyarray, FINALFUNC = first_el ); select first_el_agg_f8(x::float8) from generate_series(1,10) x; diff --git a/src/test/regress/sql/polymorphism.sql b/src/test/regress/sql/polymorphism.sql index 70a21c8978..d98a74c3f6 100644 --- a/src/test/regress/sql/polymorphism.sql +++ b/src/test/regress/sql/polymorphism.sql @@ -549,7 +549,10 @@ create aggregate build_group(int8, integer) ( -- check proper resolution of data types for polymorphic transfn/finalfn -create function first_el(anycompatiblearray) returns anycompatible as +create function first_el_transfn(anyarray, anyelement) returns anyarray as +'select $1 || $2' language sql immutable; + +create function first_el(anyarray) returns anyelement as 'select $1[1]' language sql strict immutable; create aggregate first_el_agg_f8(float8) ( @@ -558,9 +561,9 @@ create aggregate first_el_agg_f8(float8) ( FINALFUNC = first_el ); -create aggregate first_el_agg_any(anycompatible) ( - SFUNC = array_append, - STYPE = anycompatiblearray, +create aggregate first_el_agg_any(anyelement) ( + SFUNC = first_el_transfn, + STYPE = anyarray, FINALFUNC = first_el ); diff --git a/src/test/regress/expected/polymorphism.out b/src/test/regress/expected/polymorphism.out index 1ff40764d9..236b2532b3 100644 --- a/src/test/regress/expected/polymorphism.out +++ b/src/test/regress/expected/polymorphism.out @@ -786,6 +786,8 @@ create aggregate build_group(int8, integer) ( STYPE = int8[] ); -- check proper resolution of data types for polymorphic transfn/finalfn +create function first_el_transfn(anyarray, anyelement) returns anyarray as +'select $1 || $2' language sql immutable; create function first_el(anyarray) returns anyelement as 'select $1[1]' language sql strict immutable; create aggregate first_el_agg_f8(float8) ( @@ -794,7 +796,7 @@ create aggregate first_el_agg_f8(float8) ( FINALFUNC = first_el ); create aggregate first_el_agg_any(anyelement) ( - SFUNC = array_append, + SFUNC = first_el_transfn, STYPE = anyarray, FINALFUNC = first_el ); diff --git a/src/test/regress/sql/polymorphism.sql b/src/test/regress/sql/polymorphism.sql index e5222f1f81..d2e302c330 100644 --- a/src/test/regress/sql/polymorphism.sql +++ b/src/test/regress/sql/polymorphism.sql @@ -549,6 +549,9 @@ create aggregate build_group(int8, integer) ( -- check proper resolution of data types for polymorphic transfn/finalfn +create function first_el_transfn(anyarray, anyelement) returns anyarray as +'select $1 || $2' language sql immutable; + create function first_el(anyarray) returns anyelement as 'select $1[1]' language sql strict immutable; @@ -559,7 +562,7 @@ create aggregate first_el_agg_f8(float8) ( ); create aggregate first_el_agg_any(anyelement) ( - SFUNC = array_append, + SFUNC = first_el_transfn, STYPE = anyarray, FINALFUNC = first_el );
pgsql: Tag refs/tags/REL_12_5 was created
Tag refs/tags/REL_12_5 was created.
pgsql: Tag refs/tags/REL_10_15 was created
Tag refs/tags/REL_10_15 was created.
pgsql: Tag refs/tags/REL9_5_24 was created
Tag refs/tags/REL9_5_24 was created.
pgsql: Tag refs/tags/REL_13_1 was created
Tag refs/tags/REL_13_1 was created.
pgsql: Tag refs/tags/REL9_6_20 was created
Tag refs/tags/REL9_6_20 was created.
pgsql: Tag refs/tags/REL_11_10 was created
Tag refs/tags/REL_11_10 was created.
pgsql: Work around cross-version-upgrade issues created by commit 9e38c
Work around cross-version-upgrade issues created by commit 9e38c2bb5. Summarily changing the STYPE of regression-test aggregates that depend on array_append or array_cat is an issue for the buildfarm's cross-version-upgrade tests, because those aggregates (as defined in the back branches) now won't load into HEAD. Although this seems like only a minimal risk for genuine user-defined aggregates, we need to do something for the buildfarm. Hence, adjust the aggregate definitions, in both HEAD and the back branches. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5ce51f8280d3e2a59dbcd93c9d8244e3bf96944d Modified Files -- src/test/regress/expected/polymorphism.out | 24 +--- src/test/regress/sql/polymorphism.sql | 13 - 2 files changed, 21 insertions(+), 16 deletions(-)
pgsql: Work around cross-version-upgrade issues created by commit 9e38c
Work around cross-version-upgrade issues created by commit 9e38c2bb5. Summarily changing the STYPE of regression-test aggregates that depend on array_append or array_cat is an issue for the buildfarm's cross-version-upgrade tests, because those aggregates (as defined in the back branches) now won't load into HEAD. Although this seems like only a minimal risk for genuine user-defined aggregates, we need to do something for the buildfarm. Hence, adjust the aggregate definitions, in both HEAD and the back branches. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cea97d98f1674fa4d0c1174b32dcdc44d9d5e620 Modified Files -- src/test/regress/expected/polymorphism.out | 24 +--- src/test/regress/sql/polymorphism.sql | 13 - 2 files changed, 21 insertions(+), 16 deletions(-)
pgsql: Work around cross-version-upgrade issues created by commit 9e38c
Work around cross-version-upgrade issues created by commit 9e38c2bb5. Summarily changing the STYPE of regression-test aggregates that depend on array_append or array_cat is an issue for the buildfarm's cross-version-upgrade tests, because those aggregates (as defined in the back branches) now won't load into HEAD. Although this seems like only a minimal risk for genuine user-defined aggregates, we need to do something for the buildfarm. Hence, adjust the aggregate definitions, in both HEAD and the back branches. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5c456d30807136e47ea936d67946cfada3f0e71c Modified Files -- src/test/regress/expected/polymorphism.out | 24 +--- src/test/regress/sql/polymorphism.sql | 13 - 2 files changed, 21 insertions(+), 16 deletions(-)
pgsql: Work around cross-version-upgrade issues created by commit 9e38c
Work around cross-version-upgrade issues created by commit 9e38c2bb5. Summarily changing the STYPE of regression-test aggregates that depend on array_append or array_cat is an issue for the buildfarm's cross-version-upgrade tests, because those aggregates (as defined in the back branches) now won't load into HEAD. Although this seems like only a minimal risk for genuine user-defined aggregates, we need to do something for the buildfarm. Hence, adjust the aggregate definitions, in both HEAD and the back branches. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6c91e28224f6d7599b7148e28709e7ed825982b8 Modified Files -- src/test/regress/expected/polymorphism.out | 20 ++-- src/test/regress/sql/polymorphism.sql | 8 2 files changed, 14 insertions(+), 14 deletions(-)
pgsql: Work around cross-version-upgrade issues created by commit 9e38c
Work around cross-version-upgrade issues created by commit 9e38c2bb5. Summarily changing the STYPE of regression-test aggregates that depend on array_append or array_cat is an issue for the buildfarm's cross-version-upgrade tests, because those aggregates (as defined in the back branches) now won't load into HEAD. Although this seems like only a minimal risk for genuine user-defined aggregates, we need to do something for the buildfarm. Hence, adjust the aggregate definitions, in both HEAD and the back branches. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/253f02c46f0e999d2970396709b1df08590ccfb7 Modified Files -- src/test/regress/expected/polymorphism.out | 24 +--- src/test/regress/sql/polymorphism.sql | 13 - 2 files changed, 21 insertions(+), 16 deletions(-)
pgsql: Work around cross-version-upgrade issues created by commit 9e38c
Work around cross-version-upgrade issues created by commit 9e38c2bb5. Summarily changing the STYPE of regression-test aggregates that depend on array_append or array_cat is an issue for the buildfarm's cross-version-upgrade tests, because those aggregates (as defined in the back branches) now won't load into HEAD. Although this seems like only a minimal risk for genuine user-defined aggregates, we need to do something for the buildfarm. Hence, adjust the aggregate definitions, in both HEAD and the back branches. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/97f73a978fc1aca59c6ad765548ce0096d95a923 Modified Files -- src/test/regress/expected/polymorphism.out | 32 -- src/test/regress/sql/polymorphism.sql | 21 +++- 2 files changed, 29 insertions(+), 24 deletions(-)
pgsql: Work around cross-version-upgrade issues created by commit 9e38c
Work around cross-version-upgrade issues created by commit 9e38c2bb5. Summarily changing the STYPE of regression-test aggregates that depend on array_append or array_cat is an issue for the buildfarm's cross-version-upgrade tests, because those aggregates (as defined in the back branches) now won't load into HEAD. Although this seems like only a minimal risk for genuine user-defined aggregates, we need to do something for the buildfarm. Hence, adjust the aggregate definitions, in both HEAD and the back branches. Discussion: https://postgr.es/m/[email protected] Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d3d4f7233a3e16dcbaa95f62e7559d147790b574 Modified Files -- src/test/regress/expected/polymorphism.out | 24 +--- src/test/regress/sql/polymorphism.sql | 13 - 2 files changed, 21 insertions(+), 16 deletions(-)
pgsql: doc: fix spelling "connction" to "connection"
doc: fix spelling "connction" to "connection" Was wrong in commit 1a9388bd0f. Reported-by: Tom Lane, Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/efc306935de1b7de0ab696a54193f57b26268207 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- doc/src/sgml/ref/pg_dumpall.sgml| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: doc: fix spelling "connction" to "connection"
doc: fix spelling "connction" to "connection" Was wrong in commit 1a9388bd0f. Reported-by: Tom Lane, Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f93f1a21ae62fe4650335d5818b806f86928d2c2 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- doc/src/sgml/ref/pg_dumpall.sgml| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: doc: fix spelling "connction" to "connection"
doc: fix spelling "connction" to "connection" Was wrong in commit 1a9388bd0f. Reported-by: Tom Lane, Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9fed2b5b2eddba03bda7d62376186b141630ce38 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- doc/src/sgml/ref/pg_dumpall.sgml| 2 +- doc/src/sgml/ref/pg_receivewal.sgml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
pgsql: doc: fix spelling "connction" to "connection"
doc: fix spelling "connction" to "connection" Was wrong in commit 1a9388bd0f. Reported-by: Tom Lane, Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/19fd4f20b6a75058ca5be8037da529bb8cd55898 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- doc/src/sgml/ref/pg_dumpall.sgml| 2 +- doc/src/sgml/ref/pg_receivewal.sgml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
pgsql: doc: fix spelling "connction" to "connection"
doc: fix spelling "connction" to "connection" Was wrong in commit 1a9388bd0f. Reported-by: Tom Lane, Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b8b6a0124b21edd4aed24217a8e5ecf621ccd661 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- doc/src/sgml/ref/pg_dumpall.sgml| 2 +- doc/src/sgml/ref/pg_receivewal.sgml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
pgsql: doc: fix spelling "connction" to "connection"
doc: fix spelling "connction" to "connection" Was wrong in commit 1a9388bd0f. Reported-by: Tom Lane, Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ceb883d2a3622e01ed30895f3515e03897993423 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- doc/src/sgml/ref/pg_dumpall.sgml| 2 +- doc/src/sgml/ref/pg_receivewal.sgml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
pgsql: doc: fix spelling "connction" to "connection"
doc: fix spelling "connction" to "connection" Was wrong in commit 1a9388bd0f. Reported-by: Tom Lane, Justin Pryzby Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1393acb3836d32e512801bb00f0cc6b4d2a58dc8 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- doc/src/sgml/ref/pg_dumpall.sgml| 2 +- doc/src/sgml/ref/pg_receivewal.sgml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
pgsql: Fix and simplify some usages of TimestampDifference().
Fix and simplify some usages of TimestampDifference(). Introduce TimestampDifferenceMilliseconds() to simplify callers that would rather have the difference in milliseconds, instead of the select()-oriented seconds-and-microseconds format. This gets rid of at least one integer division per call, and it eliminates some apparently-easy-to-mess-up arithmetic. Two of these call sites were in fact wrong: * pg_prewarm's autoprewarm_main() forgot to multiply the seconds by 1000, thus ending up with a delay 1000X shorter than intended. That doesn't quite make it a busy-wait, but close. * postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute microseconds not milliseconds, thus ending up with a delay 1000X longer than intended. Somebody along the way had noticed this problem but misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather than fixing the units. This was relatively harmless in context, because we don't care that much about exactly how long this delay is; still, it's wrong. There are a few more callers of TimestampDifference() that don't have a direct need for seconds-and-microseconds, but can't use TimestampDifferenceMilliseconds() either because they do need microsecond precision or because they might possibly deal with intervals long enough to overflow 32-bit milliseconds. It might be worth inventing another API to improve that, but that seems outside the scope of this patch; so those callers are untouched here. Given the fact that we are fixing some bugs, and the likelihood that future patches might want to back-patch code that uses this new API, back-patch to all supported branches. Alexey Kondratov and Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/171c457cd06051b5910cf357ea6a77643b69088a Modified Files -- contrib/pg_prewarm/autoprewarm.c | 12 ++--- contrib/postgres_fdw/connection.c | 9 +--- src/backend/access/transam/xlog.c | 84 -- src/backend/replication/walreceiverfuncs.c | 25 ++--- src/backend/replication/walsender.c| 8 +-- src/backend/utils/adt/timestamp.c | 38 -- src/include/utils/timestamp.h | 2 + 7 files changed, 81 insertions(+), 97 deletions(-)
pgsql: Fix and simplify some usages of TimestampDifference().
Fix and simplify some usages of TimestampDifference(). Introduce TimestampDifferenceMilliseconds() to simplify callers that would rather have the difference in milliseconds, instead of the select()-oriented seconds-and-microseconds format. This gets rid of at least one integer division per call, and it eliminates some apparently-easy-to-mess-up arithmetic. Two of these call sites were in fact wrong: * pg_prewarm's autoprewarm_main() forgot to multiply the seconds by 1000, thus ending up with a delay 1000X shorter than intended. That doesn't quite make it a busy-wait, but close. * postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute microseconds not milliseconds, thus ending up with a delay 1000X longer than intended. Somebody along the way had noticed this problem but misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather than fixing the units. This was relatively harmless in context, because we don't care that much about exactly how long this delay is; still, it's wrong. There are a few more callers of TimestampDifference() that don't have a direct need for seconds-and-microseconds, but can't use TimestampDifferenceMilliseconds() either because they do need microsecond precision or because they might possibly deal with intervals long enough to overflow 32-bit milliseconds. It might be worth inventing another API to improve that, but that seems outside the scope of this patch; so those callers are untouched here. Given the fact that we are fixing some bugs, and the likelihood that future patches might want to back-patch code that uses this new API, back-patch to all supported branches. Alexey Kondratov and Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cd39c23a21ac46009d21a51db7438bba9d5d1941 Modified Files -- contrib/postgres_fdw/connection.c | 9 +-- src/backend/access/transam/xlog.c | 88 -- src/backend/replication/walreceiverfuncs.c | 25 ++--- src/backend/replication/walsender.c| 8 +-- src/backend/utils/adt/timestamp.c | 38 - src/include/utils/timestamp.h | 2 + 6 files changed, 78 insertions(+), 92 deletions(-)
pgsql: Fix and simplify some usages of TimestampDifference().
Fix and simplify some usages of TimestampDifference(). Introduce TimestampDifferenceMilliseconds() to simplify callers that would rather have the difference in milliseconds, instead of the select()-oriented seconds-and-microseconds format. This gets rid of at least one integer division per call, and it eliminates some apparently-easy-to-mess-up arithmetic. Two of these call sites were in fact wrong: * pg_prewarm's autoprewarm_main() forgot to multiply the seconds by 1000, thus ending up with a delay 1000X shorter than intended. That doesn't quite make it a busy-wait, but close. * postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute microseconds not milliseconds, thus ending up with a delay 1000X longer than intended. Somebody along the way had noticed this problem but misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather than fixing the units. This was relatively harmless in context, because we don't care that much about exactly how long this delay is; still, it's wrong. There are a few more callers of TimestampDifference() that don't have a direct need for seconds-and-microseconds, but can't use TimestampDifferenceMilliseconds() either because they do need microsecond precision or because they might possibly deal with intervals long enough to overflow 32-bit milliseconds. It might be worth inventing another API to improve that, but that seems outside the scope of this patch; so those callers are untouched here. Given the fact that we are fixing some bugs, and the likelihood that future patches might want to back-patch code that uses this new API, back-patch to all supported branches. Alexey Kondratov and Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e87139b43345583548fbc5a5c973a9c6763efce3 Modified Files -- contrib/postgres_fdw/connection.c | 9 +-- src/backend/access/transam/xlog.c | 90 -- src/backend/replication/walreceiverfuncs.c | 25 ++--- src/backend/replication/walsender.c| 8 +-- src/backend/utils/adt/timestamp.c | 38 - src/include/utils/timestamp.h | 2 + 6 files changed, 79 insertions(+), 93 deletions(-)
pgsql: Fix and simplify some usages of TimestampDifference().
Fix and simplify some usages of TimestampDifference(). Introduce TimestampDifferenceMilliseconds() to simplify callers that would rather have the difference in milliseconds, instead of the select()-oriented seconds-and-microseconds format. This gets rid of at least one integer division per call, and it eliminates some apparently-easy-to-mess-up arithmetic. Two of these call sites were in fact wrong: * pg_prewarm's autoprewarm_main() forgot to multiply the seconds by 1000, thus ending up with a delay 1000X shorter than intended. That doesn't quite make it a busy-wait, but close. * postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute microseconds not milliseconds, thus ending up with a delay 1000X longer than intended. Somebody along the way had noticed this problem but misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather than fixing the units. This was relatively harmless in context, because we don't care that much about exactly how long this delay is; still, it's wrong. There are a few more callers of TimestampDifference() that don't have a direct need for seconds-and-microseconds, but can't use TimestampDifferenceMilliseconds() either because they do need microsecond precision or because they might possibly deal with intervals long enough to overflow 32-bit milliseconds. It might be worth inventing another API to improve that, but that seems outside the scope of this patch; so those callers are untouched here. Given the fact that we are fixing some bugs, and the likelihood that future patches might want to back-patch code that uses this new API, back-patch to all supported branches. Alexey Kondratov and Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3a89ea0eb64a1b50b27de1965fdb2173a04d5e11 Modified Files -- contrib/pg_prewarm/autoprewarm.c | 12 ++-- contrib/postgres_fdw/connection.c | 9 +-- src/backend/access/transam/xlog.c | 90 -- src/backend/replication/walreceiverfuncs.c | 25 ++--- src/backend/replication/walsender.c| 8 +-- src/backend/utils/adt/timestamp.c | 38 - src/include/utils/timestamp.h | 2 + 7 files changed, 84 insertions(+), 100 deletions(-)
pgsql: Fix and simplify some usages of TimestampDifference().
Fix and simplify some usages of TimestampDifference(). Introduce TimestampDifferenceMilliseconds() to simplify callers that would rather have the difference in milliseconds, instead of the select()-oriented seconds-and-microseconds format. This gets rid of at least one integer division per call, and it eliminates some apparently-easy-to-mess-up arithmetic. Two of these call sites were in fact wrong: * pg_prewarm's autoprewarm_main() forgot to multiply the seconds by 1000, thus ending up with a delay 1000X shorter than intended. That doesn't quite make it a busy-wait, but close. * postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute microseconds not milliseconds, thus ending up with a delay 1000X longer than intended. Somebody along the way had noticed this problem but misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather than fixing the units. This was relatively harmless in context, because we don't care that much about exactly how long this delay is; still, it's wrong. There are a few more callers of TimestampDifference() that don't have a direct need for seconds-and-microseconds, but can't use TimestampDifferenceMilliseconds() either because they do need microsecond precision or because they might possibly deal with intervals long enough to overflow 32-bit milliseconds. It might be worth inventing another API to improve that, but that seems outside the scope of this patch; so those callers are untouched here. Given the fact that we are fixing some bugs, and the likelihood that future patches might want to back-patch code that uses this new API, back-patch to all supported branches. Alexey Kondratov and Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ec29427ce2a451e7fef7a22de6db8147d8a80994 Modified Files -- contrib/pg_prewarm/autoprewarm.c | 12 ++--- contrib/postgres_fdw/connection.c | 9 +--- src/backend/access/transam/xlog.c | 85 +++--- src/backend/replication/walreceiverfuncs.c | 25 ++--- src/backend/replication/walsender.c| 8 +-- src/backend/utils/adt/timestamp.c | 38 +++-- src/include/utils/timestamp.h | 2 + 7 files changed, 80 insertions(+), 99 deletions(-)
pgsql: Fix and simplify some usages of TimestampDifference().
Fix and simplify some usages of TimestampDifference(). Introduce TimestampDifferenceMilliseconds() to simplify callers that would rather have the difference in milliseconds, instead of the select()-oriented seconds-and-microseconds format. This gets rid of at least one integer division per call, and it eliminates some apparently-easy-to-mess-up arithmetic. Two of these call sites were in fact wrong: * pg_prewarm's autoprewarm_main() forgot to multiply the seconds by 1000, thus ending up with a delay 1000X shorter than intended. That doesn't quite make it a busy-wait, but close. * postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute microseconds not milliseconds, thus ending up with a delay 1000X longer than intended. Somebody along the way had noticed this problem but misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather than fixing the units. This was relatively harmless in context, because we don't care that much about exactly how long this delay is; still, it's wrong. There are a few more callers of TimestampDifference() that don't have a direct need for seconds-and-microseconds, but can't use TimestampDifferenceMilliseconds() either because they do need microsecond precision or because they might possibly deal with intervals long enough to overflow 32-bit milliseconds. It might be worth inventing another API to improve that, but that seems outside the scope of this patch; so those callers are untouched here. Given the fact that we are fixing some bugs, and the likelihood that future patches might want to back-patch code that uses this new API, back-patch to all supported branches. Alexey Kondratov and Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/210564a74409f79cb1441fab62c4154dd148840f Modified Files -- contrib/postgres_fdw/connection.c | 9 +-- src/backend/access/transam/xlog.c | 88 -- src/backend/replication/walreceiverfuncs.c | 25 ++--- src/backend/replication/walsender.c| 8 +-- src/backend/utils/adt/timestamp.c | 38 - src/include/utils/timestamp.h | 2 + 6 files changed, 78 insertions(+), 92 deletions(-)
pgsql: Fix and simplify some usages of TimestampDifference().
Fix and simplify some usages of TimestampDifference(). Introduce TimestampDifferenceMilliseconds() to simplify callers that would rather have the difference in milliseconds, instead of the select()-oriented seconds-and-microseconds format. This gets rid of at least one integer division per call, and it eliminates some apparently-easy-to-mess-up arithmetic. Two of these call sites were in fact wrong: * pg_prewarm's autoprewarm_main() forgot to multiply the seconds by 1000, thus ending up with a delay 1000X shorter than intended. That doesn't quite make it a busy-wait, but close. * postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute microseconds not milliseconds, thus ending up with a delay 1000X longer than intended. Somebody along the way had noticed this problem but misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather than fixing the units. This was relatively harmless in context, because we don't care that much about exactly how long this delay is; still, it's wrong. There are a few more callers of TimestampDifference() that don't have a direct need for seconds-and-microseconds, but can't use TimestampDifferenceMilliseconds() either because they do need microsecond precision or because they might possibly deal with intervals long enough to overflow 32-bit milliseconds. It might be worth inventing another API to improve that, but that seems outside the scope of this patch; so those callers are untouched here. Given the fact that we are fixing some bugs, and the likelihood that future patches might want to back-patch code that uses this new API, back-patch to all supported branches. Alexey Kondratov and Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/afce7908d7062d94ac60fd4de5f98aaed134c2c7 Modified Files -- contrib/pg_prewarm/autoprewarm.c | 12 ++--- contrib/postgres_fdw/connection.c | 9 +--- src/backend/access/transam/xlog.c | 85 +++--- src/backend/replication/walreceiverfuncs.c | 25 ++--- src/backend/replication/walsender.c| 8 +-- src/backend/utils/adt/timestamp.c | 38 +++-- src/include/utils/timestamp.h | 2 + 7 files changed, 80 insertions(+), 99 deletions(-)
pgsql: Fix cases of discarding result from list API functions
Fix cases of discarding result from list API functions Two cases violated list APIs by throwing away the return value. While the code was technically correct, it relied on internal knowledge of the list implementation, and the code wasn't really gaining anything that way. It is planned to make this a compiler warning in the future, so just fix these cases by assigning the return value properly. Reviewed-by: Michael Paquier Discussion: https://www.postgresql.org/message-id/flat/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c77f6f50e4187bed38d1d36ae16b0c248e286d15 Modified Files -- src/backend/commands/lockcmds.c | 2 +- src/backend/parser/analyze.c| 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-)
