pgsql: postgres_fdw: Fix costing of pre-sorted foreign paths with local
postgres_fdw: Fix costing of pre-sorted foreign paths with local stats. Commit aa09cd242 modified estimate_path_cost_size() so that it reuses cached costs of a basic foreign path for a given foreign-base/join relation when costing pre-sorted foreign paths for that relation, but it incorrectly re-computed retrieved_rows, an estimated number of rows fetched from the remote side, which is needed for costing both the basic and pre-sorted foreign paths. To fix, handle retrieved_rows the same way as the cached costs: store in that relation's fpinfo the retrieved_rows estimate computed for costing the basic foreign path, and reuse it when costing the pre-sorted foreign paths. Also, reuse the rows/width estimates stored in that relation's fpinfo when costing the pre-sorted foreign paths, to make the code consistent. In commit ffab494a4, to extend the costing mentioned above to the foreign-grouping case, I made a change to add_foreign_grouping_paths() to store in a given foreign-grouped relation's RelOptInfo the rows estimate for that relation for reuse, but this patch makes that change unnecessary since we already store the row estimate in that relation's fpinfo, which this patch reuses when costing a foreign path for that relation with the sortClause ordering; remove that change. In passing, fix thinko in commit 7012b132d: in estimate_path_cost_size(), the width estimate for a given foreign-grouped relation to be stored in that relation's fpinfo was reset incorrectly when costing a basic foreign path for that relation with local stats. Apply the patch to HEAD only to avoid destabilizing existing plan choices. Author: Etsuro Fujita Discussion: https://postgr.es/m/CAPmGK17jaJLPDEkgnP2VmkOg=5wt8yq1cqssu8jrpz_nse+...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/08d2d58a2a1c8ef8d39e8132d39ee14a1d029500 Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 95 ++--- contrib/postgres_fdw/postgres_fdw.h | 9 +++- 2 files changed, 63 insertions(+), 41 deletions(-)
pgsql: doc: PG 12 relnotes, add mention of single-child optimization
doc: PG 12 relnotes, add mention of single-child optimization Add mention of single-child optimization for partitions and UNION ALL. Reported-by: David Rowley Discussion: https://postgr.es/m/CAKJS1f8R8riwBXw==7ijV=UZNuhP+3qXgDBKSiM+=_ctf4m...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b9a0724cf7a3ecf19098ffd26e52bb800c5c Modified Files -- doc/src/sgml/release-12.sgml | 12 1 file changed, 12 insertions(+)
Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Alvaro Herrera writes: > Avoid spurious deadlocks when upgrading a tuple lock I'm now getting heapam.c: In function 'heap_lock_tuple': heapam.c:4041: warning: 'skip_tuple_lock' may be used uninitialized in this function Please fix. regards, tom lane
Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
On 2019-Jun-14, Tom Lane wrote: > Alvaro Herrera writes: > > Avoid spurious deadlocks when upgrading a tuple lock > > I'm now getting > > heapam.c: In function 'heap_lock_tuple': > heapam.c:4041: warning: 'skip_tuple_lock' may be used uninitialized in this > function Hm, I don't get that warning. Does this patch silence it, please? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql: Attempt to identify system timezone by reading /etc/localtime sy
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Back-patch of commit 23bd3cec6. The original intention was to not back-patch, since this can result in cosmetic behavioral changes --- for example, on my own workstation initdb now chooses "America/New_York", where it used to prefer "US/Eastern" which is equivalent and shorter. However, our hand has been more or less forced by tzdb update 2019a, which made the "UCT" zone fully equivalent to "UTC". Our old code now prefers "UCT" on the grounds of it being alphabetically first, and that's making nobody happy. Choosing the alias indicated by /etc/localtime is a more defensible behavior. (Users who don't like the results can always force the decision by setting the TZ environment variable before running initdb.) Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812...@sss.pgh.pa.us Discussion: https://postgr.es/m/20190604085735.gd24...@msg.df7cb.de Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/995b4fe0b14fddb8cbe349809116e2bad260fd31 Modified Files -- src/bin/initdb/findtimezone.c | 136 ++--- src/bin/initdb/initdb.c| 8 +- src/interfaces/ecpg/pgtypeslib/dt_common.c | 2 +- 3 files changed, 133 insertions(+), 13 deletions(-)
pgsql: Attempt to identify system timezone by reading /etc/localtime sy
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Back-patch of commit 23bd3cec6. The original intention was to not back-patch, since this can result in cosmetic behavioral changes --- for example, on my own workstation initdb now chooses "America/New_York", where it used to prefer "US/Eastern" which is equivalent and shorter. However, our hand has been more or less forced by tzdb update 2019a, which made the "UCT" zone fully equivalent to "UTC". Our old code now prefers "UCT" on the grounds of it being alphabetically first, and that's making nobody happy. Choosing the alias indicated by /etc/localtime is a more defensible behavior. (Users who don't like the results can always force the decision by setting the TZ environment variable before running initdb.) Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812...@sss.pgh.pa.us Discussion: https://postgr.es/m/20190604085735.gd24...@msg.df7cb.de Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8de574aa8bf7130f8291fc0be97e19a8074d2e05 Modified Files -- src/bin/initdb/findtimezone.c | 136 ++--- src/bin/initdb/initdb.c| 8 +- src/interfaces/ecpg/pgtypeslib/dt_common.c | 2 +- 3 files changed, 133 insertions(+), 13 deletions(-)
pgsql: Attempt to identify system timezone by reading /etc/localtime sy
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Back-patch of commit 23bd3cec6. The original intention was to not back-patch, since this can result in cosmetic behavioral changes --- for example, on my own workstation initdb now chooses "America/New_York", where it used to prefer "US/Eastern" which is equivalent and shorter. However, our hand has been more or less forced by tzdb update 2019a, which made the "UCT" zone fully equivalent to "UTC". Our old code now prefers "UCT" on the grounds of it being alphabetically first, and that's making nobody happy. Choosing the alias indicated by /etc/localtime is a more defensible behavior. (Users who don't like the results can always force the decision by setting the TZ environment variable before running initdb.) Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812...@sss.pgh.pa.us Discussion: https://postgr.es/m/20190604085735.gd24...@msg.df7cb.de Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/75b0f21e1b197ba1e2f24a05b214dc1a2904db4f Modified Files -- src/bin/initdb/findtimezone.c | 136 ++--- src/bin/initdb/initdb.c| 8 +- src/interfaces/ecpg/pgtypeslib/dt_common.c | 2 +- 3 files changed, 133 insertions(+), 13 deletions(-)
pgsql: Attempt to identify system timezone by reading /etc/localtime sy
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Back-patch of commit 23bd3cec6. The original intention was to not back-patch, since this can result in cosmetic behavioral changes --- for example, on my own workstation initdb now chooses "America/New_York", where it used to prefer "US/Eastern" which is equivalent and shorter. However, our hand has been more or less forced by tzdb update 2019a, which made the "UCT" zone fully equivalent to "UTC". Our old code now prefers "UCT" on the grounds of it being alphabetically first, and that's making nobody happy. Choosing the alias indicated by /etc/localtime is a more defensible behavior. (Users who don't like the results can always force the decision by setting the TZ environment variable before running initdb.) Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812...@sss.pgh.pa.us Discussion: https://postgr.es/m/20190604085735.gd24...@msg.df7cb.de Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/77dc741a1727f16ce76dcdc6fd5c23bb8267091f Modified Files -- src/bin/initdb/findtimezone.c | 136 ++--- src/bin/initdb/initdb.c| 8 +- src/interfaces/ecpg/pgtypeslib/dt_common.c | 2 +- 3 files changed, 133 insertions(+), 13 deletions(-)
pgsql: Attempt to identify system timezone by reading /etc/localtime sy
Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Back-patch of commit 23bd3cec6. The original intention was to not back-patch, since this can result in cosmetic behavioral changes --- for example, on my own workstation initdb now chooses "America/New_York", where it used to prefer "US/Eastern" which is equivalent and shorter. However, our hand has been more or less forced by tzdb update 2019a, which made the "UCT" zone fully equivalent to "UTC". Our old code now prefers "UCT" on the grounds of it being alphabetically first, and that's making nobody happy. Choosing the alias indicated by /etc/localtime is a more defensible behavior. (Users who don't like the results can always force the decision by setting the TZ environment variable before running initdb.) Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812...@sss.pgh.pa.us Discussion: https://postgr.es/m/20190604085735.gd24...@msg.df7cb.de Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/37011bcb30a9dff84b83a868e5f44c300ddc2f1f Modified Files -- src/bin/initdb/findtimezone.c | 136 ++--- src/bin/initdb/initdb.c| 8 +- src/interfaces/ecpg/pgtypeslib/dt_common.c | 2 +- 3 files changed, 133 insertions(+), 13 deletions(-)
Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Alvaro Herrera writes: > On 2019-Jun-14, Tom Lane wrote: >> I'm now getting >> heapam.c: In function 'heap_lock_tuple': >> heapam.c:4041: warning: 'skip_tuple_lock' may be used uninitialized in this >> function > Hm, I don't get that warning. Does this patch silence it, please? Uh, no patch attached? But initializing the variable where it's declared would certainly silence it. regards, tom lane
Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
I wrote: >> Hm, I don't get that warning. Does this patch silence it, please? > Uh, no patch attached? But initializing the variable where it's > declared would certainly silence it. BTW, after looking around a bit I wonder if this complaint isn't exposing an actual logic bug. Shouldn't skip_tuple_lock have a lifetime similar to first_time? regards, tom lane
pgsql: Silence compiler warning
Silence compiler warning Introduced in de87a084c0a5. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/744639739c7c6a53bcbf4cd6fe765d7ebd89716a Modified Files -- src/backend/access/heap/heapam.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Silence compiler warning
Silence compiler warning Introduced in de87a084c0a5. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/563357a12c9b1cdbae29a2d0d09eb9f2c01da4d6 Modified Files -- src/backend/access/heap/heapam.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Silence compiler warning
Silence compiler warning Introduced in de87a084c0a5. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3da73d6839dc47f1f47ca57974bf28e5abd9b572 Modified Files -- src/backend/access/heap/heapam.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Silence compiler warning
Silence compiler warning Introduced in de87a084c0a5. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1f8f144fe3a98928a026af9c2a45e57a962cc90d Modified Files -- src/backend/access/heap/heapam.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
On 2019-Jun-14, Tom Lane wrote: > I wrote: > >> Hm, I don't get that warning. Does this patch silence it, please? > > > Uh, no patch attached? But initializing the variable where it's > > declared would certainly silence it. > > BTW, after looking around a bit I wonder if this complaint isn't > exposing an actual logic bug. Shouldn't skip_tuple_lock have > a lifetime similar to first_time? I think you're right. I should come up with a test case that exercises that case. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql: First-draft release notes for 11.4.
First-draft release notes for 11.4. As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0995cefa74510ee0e38d1bf095b2eef2c1ea37c4 Modified Files -- doc/src/sgml/release-11.sgml | 528 +++ 1 file changed, 528 insertions(+)
pgsql: Tweak libpq's PQhost, PQhostaddr, and psql's \connect
Tweak libpq's PQhost, PQhostaddr, and psql's \connect Fixes some problems introduced by 6e5f8d489acc: * When reusing conninfo data from the previous connection in \connect, the host address should only be reused if it was specified as hostaddr; if it wasn't, then 'host' is resolved afresh. We were reusing the same IP address, which ignores a possible DNS change as well as any other addresses that the name resolves to than the one that was used in the original connection. * PQhost, PQhostaddr: Don't present user-specified hostaddr when we have an inet_net_ntop-produced equivalent address. The latter has been put in canonical format, which is cleaner (so it produces "127.0.0.1" when given "host=2130706433", for example). * Document the hostaddr-reusing aspect of \connect. * Fix some code comments Author: Fabien Coelho Reported-by: Noah Misch Discussion: https://postgr.es/m/20190527203713.ga58...@gust.leadboat.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/313f56ce2d1b9dfd3483e4f39611baa27852835a Modified Files -- doc/src/sgml/ref/psql-ref.sgml| 3 +++ src/bin/psql/command.c| 41 ++- src/interfaces/libpq/fe-connect.c | 20 --- 3 files changed, 43 insertions(+), 21 deletions(-)
pgsql: Add pg_dumpall --rows-per-insert
Add pg_dumpall --rows-per-insert Commit 7e413a0f82c8 added that option to pg_dump, but neglected to teach pg_dumpall how to pass it along. Repair. Author: Fabien Coelho Reported-by: Peter Eisentraut Reviewed-by: David Rowley Discussion: https://postgr.es/m/45f50c59-ddbb-8cf2-eedb-81003f603...@2ndquadrant.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a193cbec1199e4e529c46645b7aecbf38956048b Modified Files -- doc/src/sgml/ref/pg_dumpall.sgml | 14 ++ src/bin/pg_dump/pg_dumpall.c | 7 +++ 2 files changed, 21 insertions(+)
