pgsql: Expand installation documentation to cover binary installations
Expand installation documentation to cover binary installations Reviewed-By: David G. Johnston, Daniel Gustafsson Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5b36221c46f9ca9c5df6a6e108790b5c6c5d2cc3 Modified Files -- doc/src/sgml/filelist.sgml | 1 + doc/src/sgml/install-binaries.sgml | 24 doc/src/sgml/install-windows.sgml | 3 ++- doc/src/sgml/installation.sgml | 2 +- doc/src/sgml/postgres.sgml | 1 + 5 files changed, 29 insertions(+), 2 deletions(-)
pgsql: Clarify documentation around pg_dump -t option
Clarify documentation around pg_dump -t option The behavior is different for different types of objects, so make that more clear. Author: Ian Barwick Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b8c4d385120cb7fe70006812234b2cbc950f4a61 Modified Files -- doc/src/sgml/ref/pg_dump.sgml | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-)
pgsql: Clarify documentation around pg_dump -t option
Clarify documentation around pg_dump -t option The behavior is different for different types of objects, so make that more clear. Author: Ian Barwick Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0639f9b8c251d152695a968c3978edca844c3cad Modified Files -- doc/src/sgml/ref/pg_dump.sgml | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-)
pgsql: Further improvements on documentation for pg_dump -t
Further improvements on documentation for pg_dump -t Ian submitted an updated patch just as I was pushing the previous one, so use this newer wording instead. Author: Ian Barwick Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/96423711918f44600c9ef91f4342984624f053bb Modified Files -- doc/src/sgml/ref/pg_dump.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Further improvements on documentation for pg_dump -t
Further improvements on documentation for pg_dump -t Ian submitted an updated patch just as I was pushing the previous one, so use this newer wording instead. Author: Ian Barwick Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1b4945e1e7162fe92aecb1cd2b373fba24c2 Modified Files -- doc/src/sgml/ref/pg_dump.sgml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Build EC members for child join rels in the right memory context
Build EC members for child join rels in the right memory context. This patch prevents crashes or wrong plans when partition-wise joins are considered during GEQO planning, as a consequence of the EquivalenceClass data structures becoming corrupt after a GEQO context reset. A remaining problem is that successive GEQO cycles will make multiple copies of the required EC members, since add_child_join_rel_equivalences has no idea that such members might exist already. For now we'll just live with that. The lack of field complaints of crashes suggests that this is a mighty little-used situation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3d69efc4f07d773329dfbd39d6ec67a025cf7339 Modified Files -- src/backend/optimizer/path/equivclass.c | 13 + 1 file changed, 13 insertions(+)
pgsql: Build EC members for child join rels in the right memory context
Build EC members for child join rels in the right memory context. This patch prevents crashes or wrong plans when partition-wise joins are considered during GEQO planning, as a consequence of the EquivalenceClass data structures becoming corrupt after a GEQO context reset. A remaining problem is that successive GEQO cycles will make multiple copies of the required EC members, since add_child_join_rel_equivalences has no idea that such members might exist already. For now we'll just live with that. The lack of field complaints of crashes suggests that this is a mighty little-used situation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d7885b1f87fa066606acc54700edee28812be8c1 Modified Files -- src/backend/optimizer/path/equivclass.c | 13 + 1 file changed, 13 insertions(+)
pgsql: Build EC members for child join rels in the right memory context
Build EC members for child join rels in the right memory context. This patch prevents crashes or wrong plans when partition-wise joins are considered during GEQO planning, as a consequence of the EquivalenceClass data structures becoming corrupt after a GEQO context reset. A remaining problem is that successive GEQO cycles will make multiple copies of the required EC members, since add_child_join_rel_equivalences has no idea that such members might exist already. For now we'll just live with that. The lack of field complaints of crashes suggests that this is a mighty little-used situation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b7f166efade004ba293f52b672961ae064d202cd Modified Files -- src/backend/optimizer/path/equivclass.c | 13 + 1 file changed, 13 insertions(+)
pgsql: pg_upgrade; change major version comparisons to use <=, not
pg_upgrade; change major version comparisons to use <=, not < This makes checking for older major versions more consistent. Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/89406a9b58a05c6f5f802c99b1587ae42e650123 Modified Files -- src/bin/pg_upgrade/check.c | 6 +++--- src/bin/pg_upgrade/function.c | 4 ++-- src/bin/pg_upgrade/pg_upgrade.c | 2 +- src/bin/pg_upgrade/server.c | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-)
pgsql: pg_upgrade; change major version comparisons to use <=, not
pg_upgrade; change major version comparisons to use <=, not < This makes checking for older major versions more consistent. Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dc3953421b436981260ff3dc658e9a6c4c3f6ebe Modified Files -- src/bin/pg_upgrade/check.c | 6 +++--- src/bin/pg_upgrade/controldata.c | 2 +- src/bin/pg_upgrade/exec.c| 6 +++--- src/bin/pg_upgrade/function.c| 4 ++-- src/bin/pg_upgrade/pg_upgrade.c | 6 +++--- src/bin/pg_upgrade/server.c | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-)
pgsql: pg_upgrade; change major version comparisons to use <=, not
pg_upgrade; change major version comparisons to use <=, not < This makes checking for older major versions more consistent. Backpatch-through: 9.5 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2cb4b8e0ae16e7091a7bd5cf94f21d2719b108e0 Modified Files -- src/bin/pg_upgrade/check.c | 6 +++--- src/bin/pg_upgrade/controldata.c | 2 +- src/bin/pg_upgrade/exec.c| 6 +++--- src/bin/pg_upgrade/function.c| 4 ++-- src/bin/pg_upgrade/pg_upgrade.c | 6 +++--- src/bin/pg_upgrade/server.c | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-)
pgsql: pg_upgrade; change major version comparisons to use <=, not
pg_upgrade; change major version comparisons to use <=, not < This makes checking for older major versions more consistent. Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0e78dcaf73b6b9d4c74b858ebb4a0464b7c726de Modified Files -- src/bin/pg_upgrade/check.c | 6 +++--- src/bin/pg_upgrade/function.c | 4 ++-- src/bin/pg_upgrade/pg_upgrade.c | 2 +- src/bin/pg_upgrade/server.c | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-)
pgsql: pg_upgrade; change major version comparisons to use <=, not
pg_upgrade; change major version comparisons to use <=, not < This makes checking for older major versions more consistent. Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1499477303d883947fec97730693f6f4e5593140 Modified Files -- src/bin/pg_upgrade/check.c | 6 +++--- src/bin/pg_upgrade/controldata.c | 2 +- src/bin/pg_upgrade/exec.c| 6 +++--- src/bin/pg_upgrade/function.c| 4 ++-- src/bin/pg_upgrade/pg_upgrade.c | 6 +++--- src/bin/pg_upgrade/server.c | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-)
pgsql: pg_upgrade; change major version comparisons to use <=, not
pg_upgrade; change major version comparisons to use <=, not < This makes checking for older major versions more consistent. Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bc1fbc960bf5efbb692f4d1bf91bf9bc6390425a Modified Files -- src/bin/pg_upgrade/check.c | 6 +++--- src/bin/pg_upgrade/controldata.c | 2 +- src/bin/pg_upgrade/exec.c| 6 +++--- src/bin/pg_upgrade/function.c| 4 ++-- src/bin/pg_upgrade/pg_upgrade.c | 6 +++--- src/bin/pg_upgrade/server.c | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-)
pgsql: pg_upgrade; change major version comparisons to use <=, not
pg_upgrade; change major version comparisons to use <=, not < This makes checking for older major versions more consistent. Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f09e2a8c6307058aa767924516bb057cc9cedef8 Modified Files -- src/bin/pg_upgrade/check.c | 6 +++--- src/bin/pg_upgrade/controldata.c | 2 +- src/bin/pg_upgrade/exec.c| 6 +++--- src/bin/pg_upgrade/function.c| 4 ++-- src/bin/pg_upgrade/pg_upgrade.c | 6 +++--- src/bin/pg_upgrade/server.c | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-)
pgsql: pg_upgrade: remove pre-8.4 code and >= 8.4 check
pg_upgrade: remove pre-8.4 code and >= 8.4 check We only support upgrading from >= 8.4 so no need for this code or tests. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493mjt-x6sppb...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/957a78222071732f53d45f64ab6d655a27e65f65 Modified Files -- src/bin/pg_upgrade/check.c | 29 +++-- src/bin/pg_upgrade/relfilenode.c | 16 ++-- 2 files changed, 13 insertions(+), 32 deletions(-)
pgsql: pg_upgrade: remove pre-8.4 code and >= 8.4 check
pg_upgrade: remove pre-8.4 code and >= 8.4 check We only support upgrading from >= 8.4 so no need for this code or tests. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493mjt-x6sppb...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c09164a0f8b02c131bf4f3d53c0c8bdebedc57c5 Modified Files -- src/bin/pg_upgrade/check.c | 29 +++-- src/bin/pg_upgrade/relfilenode.c | 16 ++-- 2 files changed, 13 insertions(+), 32 deletions(-)
pgsql: pg_upgrade: remove pre-8.4 code and >= 8.4 check
pg_upgrade: remove pre-8.4 code and >= 8.4 check We only support upgrading from >= 8.4 so no need for this code or tests. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493mjt-x6sppb...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/77971bc4f2371ce25b87b105470a39d5f21815d1 Modified Files -- src/bin/pg_upgrade/check.c | 29 +++-- src/bin/pg_upgrade/relfilenode.c | 16 ++-- 2 files changed, 13 insertions(+), 32 deletions(-)
pgsql: pg_upgrade: remove pre-8.4 code and >= 8.4 check
pg_upgrade: remove pre-8.4 code and >= 8.4 check We only support upgrading from >= 8.4 so no need for this code or tests. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493mjt-x6sppb...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/be304cf9f5665e1c19d02f1144d4f0affa0034c7 Modified Files -- src/bin/pg_upgrade/check.c | 29 +++-- src/bin/pg_upgrade/relfilenode.c | 16 ++-- 2 files changed, 13 insertions(+), 32 deletions(-)
pgsql: pg_upgrade: remove pre-8.4 code and >= 8.4 check
pg_upgrade: remove pre-8.4 code and >= 8.4 check We only support upgrading from >= 8.4 so no need for this code or tests. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493mjt-x6sppb...@mail.gmail.com Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/069179767f79c03381056b23ded0a54156674456 Modified Files -- src/bin/pg_upgrade/check.c | 29 +++-- src/bin/pg_upgrade/relfilenode.c | 16 ++-- 2 files changed, 13 insertions(+), 32 deletions(-)
pgsql: pg_upgrade: remove pre-8.4 code and >= 8.4 check
pg_upgrade: remove pre-8.4 code and >= 8.4 check We only support upgrading from >= 8.4 so no need for this code or tests. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493mjt-x6sppb...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/37c0baa4120be660f5f927fe81428c6be60b1717 Modified Files -- src/bin/pg_upgrade/check.c | 29 +++-- src/bin/pg_upgrade/relfilenode.c | 16 ++-- 2 files changed, 13 insertions(+), 32 deletions(-)
pgsql: pg_upgrade: remove pre-8.4 code and >= 8.4 check
pg_upgrade: remove pre-8.4 code and >= 8.4 check We only support upgrading from >= 8.4 so no need for this code or tests. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493mjt-x6sppb...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/700b7002f2727cd1f9e01c5def6023b78017b958 Modified Files -- src/bin/pg_upgrade/check.c | 29 +++-- src/bin/pg_upgrade/relfilenode.c | 16 ++-- 2 files changed, 13 insertions(+), 32 deletions(-)
Re: pgsql: Fix race in test of pg_switch_wal().
On Mon, Sep 14, 2020 at 05:27:07PM +0900, Michael Paquier wrote: > On Mon, Sep 14, 2020 at 06:19:38AM +, Noah Misch wrote: > > Fix race in test of pg_switch_wal(). > > > > The test failed when something added WAL between pg_switch_wal() and > > pg_current_wal_lsn(), seen on buildfarm members hornet and sungazer. > > Fix v10, v9.6 and v9.5 by making this code mirror its v13+ counterpart. > > v12 and v11 lack a counterpart. > > Thanks Noah for that, I did not notice those buildfarm failures: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2020-07-24%2010%3A24%3A56 > > It is fine to ping me or just to begin a thread if there is a problem, > I would have taken care of it. There's a new 020_archive_status.pl failure: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2020-10-05%2023%3A02%3A17 Would you like to diagnose/fix that one?
Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect
Hi Fujii-san, On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote: > postgres_fdw: reestablish new connection if cached one is detected as broken. > > In postgres_fdw, once remote connections are established, they are cached > and re-used for subsequent queries and transactions. There can be some > cases where those cached connections are unavaiable, for example, > by the restart of remote server. In these cases, previously an error was > reported and the query accessing to remote server failed if new remote > transaction failed to start because the cached connection was broken. > > This commit improves postgres_fdw so that new connection is remade > if broken connection is detected when starting new remote transaction. > This is useful to avoid unnecessary failure of queries when connection is > broken but can be reestablished. lorikeet is telling that the test introduced by this commit is unstable: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2020-10-06%2008%3A28%3A36 Some details: BEGIN; SELECT 1 FROM ft1 LIMIT 1; - ?column? --- -1 -(1 row) - +ERROR: could not receive data from server: Software caused connection abort +CONTEXT: remote SQL command: START TRANSACTION ISOLATION LEVEL REPEATABLE READ -- Michael signature.asc Description: PGP signature
Re: pgsql: Fix race in test of pg_switch_wal().
On Tue, Oct 06, 2020 at 07:03:27PM -0700, Noah Misch wrote: > There's a new 020_archive_status.pl failure: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2020-10-05%2023%3A02%3A17 > > Would you like to diagnose/fix that one? Wow, thanks. This does not looks like an issue coming directly from the test though: 2020-10-06 00:20:46.786 UTC [20906622:8] LOG: restored log file "00010003" from archive 2020-10-06 00:20:46.803 UTC [10748670:1] ERROR: could not open file "pg_xlog/00010003": No such file or directory 2020-10-06 00:20:46.880 UTC [21496712:4] psql ERROR: checkpoint request failed 2020-10-06 00:20:46.880 UTC [21496712:5] psql HINT: Consult recent messages in the server log for details. [...] error running SQL: 'psql::1: ERROR: checkpoint request failed HINT: Consult recent messages in the server log for details.' And it looks like a race condition between the checkpointer and the startup process. This failure involves the first checkpoint triggered in $standby2 after it gets created, with this standby reaching a consistent point before triggering a manual restartpoint. That's a bit strange though, the startup process considers that this segment is restored, but the checkpointer complains that it does not actually exist, so that's in contradiction with what the startup process tells us. :/ -- Michael signature.asc Description: PGP signature
pgsql: Display the names of missing columns in error during logical rep
Display the names of missing columns in error during logical replication. In logical replication when a subscriber is missing some columns, it currently emits an error message that says "some" columns are missing, but it doesn't specify the missing column names. Change that to display missing column names which makes an error to be more informative to the user. We have decided not to backpatch this commit as this is a minor usability improvement and no user has reported this. Reported-by: Bharath Rupireddy Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi and Amit Kapila Discussion: https://postgr.es/m/calj2acvkw-exh_4pmbk8tnehrz5ksuc4wddgactucjpibch...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f07707099c17e7ff66eac7d38cbd1148672f7ee4 Modified Files -- src/backend/replication/logical/relation.c | 55 -- 1 file changed, 45 insertions(+), 10 deletions(-)
Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect
On 2020/10/07 11:13, Michael Paquier wrote: Hi Fujii-san, On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote: postgres_fdw: reestablish new connection if cached one is detected as broken. In postgres_fdw, once remote connections are established, they are cached and re-used for subsequent queries and transactions. There can be some cases where those cached connections are unavaiable, for example, by the restart of remote server. In these cases, previously an error was reported and the query accessing to remote server failed if new remote transaction failed to start because the cached connection was broken. This commit improves postgres_fdw so that new connection is remade if broken connection is detected when starting new remote transaction. This is useful to avoid unnecessary failure of queries when connection is broken but can be reestablished. lorikeet is telling that the test introduced by this commit is unstable: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2020-10-06%2008%3A28%3A36 Thanks for letting me know this! Some details: BEGIN; SELECT 1 FROM ft1 LIMIT 1; - ?column? --- -1 -(1 row) - +ERROR: could not receive data from server: Software caused connection abort +CONTEXT: remote SQL command: START TRANSACTION ISOLATION LEVEL REPEATABLE READ This error means that new connection was successfully reestablished after the cached connection was terminated, and then the above connection error occurred when issuing "START TRANSACTION" command on that new connection. There seems no suspicious relevant log messages in the logfile. So I'm not sure why this error happened, yet. Per the previous discusson at [1], lorikeet sometimes seems to cause connection-relation failure in the regression test. So the cause of error that we faced today also may be lorikeet itself. [1] https://www.postgresql.org/message-id/ca+hukgl3son9iaeqgjpbxcpu_6hhzhw9x24uno14moc4bg0...@mail.gmail.com Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
