pgsql: Repair two portability oversights of new test
Repair two portability oversights of new test First, as pointed out by Tom Lane and Michael Paquier, I failed to realize that Windows' PostgresNode needs an extra pg_hba.conf line (added by PostgresNode->set_replication_conf, called internally by ->init() when 'allows_streaming=>1' is given -- but I purposefully omitted that). I think a good fix should be to have nodes with only 'has_archiving=>1' set up for replication too, but that's a bigger discussion. Fix it by calling ->set_replication_conf, which is not unprecedented, as pointed out by Andrew Dunstan. I also forgot to uncomment a ->finish() call for a pumpable IPC::Run file descriptor. Apparently this is innocuous in almost all platforms. Backpatch to 14. The older branches were added this file too, but not this particular part of the test. Discussion: https://postgr.es/m/374.1632947...@sss.pgh.pa.us Discussion: https://postgr.es/m/yvt7qwhr8jmc2...@paquier.xyz Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e3731bac52cf049bed965aa4f96cb073ed044b68 Modified Files -- src/test/recovery/t/026_overwrite_contrecord.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Repair two portability oversights of new test
Repair two portability oversights of new test First, as pointed out by Tom Lane and Michael Paquier, I failed to realize that Windows' PostgresNode needs an extra pg_hba.conf line (added by PostgresNode->set_replication_conf, called internally by ->init() when 'allows_streaming=>1' is given -- but I purposefully omitted that). I think a good fix should be to have nodes with only 'has_archiving=>1' set up for replication too, but that's a bigger discussion. Fix it by calling ->set_replication_conf, which is not unprecedented, as pointed out by Andrew Dunstan. I also forgot to uncomment a ->finish() call for a pumpable IPC::Run file descriptor. Apparently this is innocuous in almost all platforms. Backpatch to 14. The older branches were added this file too, but not this particular part of the test. Discussion: https://postgr.es/m/374.1632947...@sss.pgh.pa.us Discussion: https://postgr.es/m/yvt7qwhr8jmc2...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d03bca4d70c29cca4f09e3a0e78a56cf97e237f3 Modified Files -- src/test/recovery/t/026_overwrite_contrecord.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Re: pgsql: Fix WAL replay in presence of an incomplete record
On 2021-Sep-30, Michael Paquier wrote: > Hi Alvaro, > > On Wed, Sep 29, 2021 at 02:40:29PM +, Alvaro Herrera wrote: > > Fix WAL replay in presence of an incomplete record > > [...] > > src/test/recovery/t/026_overwrite_contrecord.pl | 207 > > > > src/test/recovery/t/idiosyncratic_copy | 20 +++ > > The builfarm is saying that this test fails on Windows: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2021-09-29%2020%3A00%3A01 > Sep 29 17:27:23 t/026_overwrite_contrecord..FAILED--Further testing > stopped: command "pg_basebackup -D... > [...] > pg_basebackup: error: connection to server at "127.0.0.1", port 55644 failed: > FATAL: no pg_hba.conf entry for replication connection from host > "127.0.0.1", user "pgrunner", no encryption Thanks. We had already discussed this in the other thread and I opted to call ->set_replication_conf instead: https://www.postgresql.org/message-id/202109292127.7q66qhxhde67%40alvherre.pgsql According to Andres, there's still going to be a failure for other reasons, but let's see what happens. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ really, I see PHP as like a strange amalgamation of C, Perl, Shell inflex: you know that "amalgam" means "mixture with mercury", more or less, right? i.e., "deadly poison"
pgsql: Treat ETIMEDOUT as indicating a non-recoverable connection failu
Treat ETIMEDOUT as indicating a non-recoverable connection failure. Add ETIMEDOUT to ALL_CONNECTION_FAILURE_ERRNOS' list of "errnos that identify hard failure of a previously-established network connection". While one could imagine that this is sometimes recoverable, the same could be said of other entries such as ENETDOWN. In support of this, handle ETIMEDOUT on par with other socket errors in relevant infrastructure, such as TranslateSocketError(). (I made a couple of cosmetic adjustments in TranslateSocketError(), too.) The code now assumes that ETIMEDOUT is defined everywhere, which it should be given that POSIX has required it since SUSv2. Perhaps this should be back-patched, but I'm hesitant to do so given the lack of previous complaints, and the hazard that there's a small ABI break on Windows from redefining the symbol. Even if we decide to do that, it'd be prudent to let this bake awhile in HEAD first. Jelte Fennema Discussion: https://postgr.es/m/am5pr83mb01782bff2978505f6d6c559af7...@am5pr83mb0178.eurprd83.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b484ddf4d2eb81736512efa35ed3e5d2a72993d8 Modified Files -- src/backend/port/win32/socket.c | 11 --- src/include/port.h | 3 ++- src/include/port/win32_port.h | 2 ++ src/port/strerror.c | 2 -- 4 files changed, 12 insertions(+), 6 deletions(-)
pgsql: Remove gratuitous environment dependency in 002_types.pl test.
Remove gratuitous environment dependency in 002_types.pl test. Computing related timestamps by subtracting "N days" is sensitive to the prevailing timezone, since we interpret that as "same local time on the N'th prior day". Even though the intervals in question are only two to four days, through remarkable bad luck they managed to cross the end of Ramadan in 2014, causing the test's output to change if timezone is set to Africa/Casablanca. (Maybe in other Muslim areas as well; I didn't check.) There's absolutely no reason for this test to exercise interval subtraction, so just get rid of that and use plain timestamptz constants representing the intended values. Per report from Andres Freund. Back-patch to v10 where this test script came in. Discussion: https://postgr.es/m/20210930183641.7lh4jhvpipvro...@alap3.anarazel.de Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/649e561f65c579630e5c31ee65308eefdd21ec93 Modified Files -- src/test/subscription/t/002_types.pl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Remove gratuitous environment dependency in 002_types.pl test.
Remove gratuitous environment dependency in 002_types.pl test. Computing related timestamps by subtracting "N days" is sensitive to the prevailing timezone, since we interpret that as "same local time on the N'th prior day". Even though the intervals in question are only two to four days, through remarkable bad luck they managed to cross the end of Ramadan in 2014, causing the test's output to change if timezone is set to Africa/Casablanca. (Maybe in other Muslim areas as well; I didn't check.) There's absolutely no reason for this test to exercise interval subtraction, so just get rid of that and use plain timestamptz constants representing the intended values. Per report from Andres Freund. Back-patch to v10 where this test script came in. Discussion: https://postgr.es/m/20210930183641.7lh4jhvpipvro...@alap3.anarazel.de Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/afc6081f6ea8fa053dafe14e609d1d8e885410f8 Modified Files -- src/test/subscription/t/002_types.pl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Remove gratuitous environment dependency in 002_types.pl test.
Remove gratuitous environment dependency in 002_types.pl test. Computing related timestamps by subtracting "N days" is sensitive to the prevailing timezone, since we interpret that as "same local time on the N'th prior day". Even though the intervals in question are only two to four days, through remarkable bad luck they managed to cross the end of Ramadan in 2014, causing the test's output to change if timezone is set to Africa/Casablanca. (Maybe in other Muslim areas as well; I didn't check.) There's absolutely no reason for this test to exercise interval subtraction, so just get rid of that and use plain timestamptz constants representing the intended values. Per report from Andres Freund. Back-patch to v10 where this test script came in. Discussion: https://postgr.es/m/20210930183641.7lh4jhvpipvro...@alap3.anarazel.de Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f2cf745a038c984092b74fe5b82b892721f9310e Modified Files -- src/test/subscription/t/002_types.pl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Remove gratuitous environment dependency in 002_types.pl test.
Remove gratuitous environment dependency in 002_types.pl test. Computing related timestamps by subtracting "N days" is sensitive to the prevailing timezone, since we interpret that as "same local time on the N'th prior day". Even though the intervals in question are only two to four days, through remarkable bad luck they managed to cross the end of Ramadan in 2014, causing the test's output to change if timezone is set to Africa/Casablanca. (Maybe in other Muslim areas as well; I didn't check.) There's absolutely no reason for this test to exercise interval subtraction, so just get rid of that and use plain timestamptz constants representing the intended values. Per report from Andres Freund. Back-patch to v10 where this test script came in. Discussion: https://postgr.es/m/20210930183641.7lh4jhvpipvro...@alap3.anarazel.de Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d30d8257ec749dd9b5b449dd4b79831481e3634e Modified Files -- src/test/subscription/t/002_types.pl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Remove gratuitous environment dependency in 002_types.pl test.
Remove gratuitous environment dependency in 002_types.pl test. Computing related timestamps by subtracting "N days" is sensitive to the prevailing timezone, since we interpret that as "same local time on the N'th prior day". Even though the intervals in question are only two to four days, through remarkable bad luck they managed to cross the end of Ramadan in 2014, causing the test's output to change if timezone is set to Africa/Casablanca. (Maybe in other Muslim areas as well; I didn't check.) There's absolutely no reason for this test to exercise interval subtraction, so just get rid of that and use plain timestamptz constants representing the intended values. Per report from Andres Freund. Back-patch to v10 where this test script came in. Discussion: https://postgr.es/m/20210930183641.7lh4jhvpipvro...@alap3.anarazel.de Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b46710dadf0c61912bb41997b1c653789acd2336 Modified Files -- src/test/subscription/t/002_types.pl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Remove gratuitous environment dependency in 002_types.pl test.
Remove gratuitous environment dependency in 002_types.pl test. Computing related timestamps by subtracting "N days" is sensitive to the prevailing timezone, since we interpret that as "same local time on the N'th prior day". Even though the intervals in question are only two to four days, through remarkable bad luck they managed to cross the end of Ramadan in 2014, causing the test's output to change if timezone is set to Africa/Casablanca. (Maybe in other Muslim areas as well; I didn't check.) There's absolutely no reason for this test to exercise interval subtraction, so just get rid of that and use plain timestamptz constants representing the intended values. Per report from Andres Freund. Back-patch to v10 where this test script came in. Discussion: https://postgr.es/m/20210930183641.7lh4jhvpipvro...@alap3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/20f8671ef69b864c25ffa59471814102c1260d78 Modified Files -- src/test/subscription/t/002_types.pl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Ensure interleaved_parts field is always initialized
Ensure interleaved_parts field is always initialized This field was recently added in db632fbca, however that commit missed one place where it should have initialized the new field to NULL. The missed location is where the PartitionBoundInfo is created for partition-wise join relations. Technically there could be interleaved partitions in a partition-wise join relation, but currently the only optimization we use this field for only does so for base rels and other member rels. So just document that we don't populate this field for join rels. Reported-by: Amit Langote Author: Amit Langote, David Rowley Reviewed-by: Amit Langote, David Rowley Discussion: https://postgr.es/m/ca+hiwqe76rps24kwhsd2cr82ua07tjc9t9reg0c7scx9n_x...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/16239c5fdf6e457f8274c49209d1fbdeab472703 Modified Files -- src/backend/partitioning/partbounds.c | 3 +++ src/include/partitioning/partbounds.h | 4 +++- 2 files changed, 6 insertions(+), 1 deletion(-)
pgsql: Doc: Move pg_stat_replication_slots view to "Collected Statistic
Doc: Move pg_stat_replication_slots view to "Collected Statistics Views" section. Commit 9868167500 added pg_stat_replication_slots view to monitor ReorderBuffer stats but mistakenly added it under "Dynamic Statistics Views" section in the docs whereas it belongs to "Collected Statistics Views" section. Author: Amit Kapila Reviewed-by: Masahiko Sawada Backpatch-through: 14, where it was introduced Discussion: https://postgr.es/m/CAA4eK1Kb5ur=oc-g4casqpojove+s8lnw1wmuy8owasjk8o...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2d44dee0281a1abf0dcb1548c910fae067f1d34d Modified Files -- doc/src/sgml/monitoring.sgml | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-)
pgsql: Doc: Move pg_stat_replication_slots view to "Collected Statistic
Doc: Move pg_stat_replication_slots view to "Collected Statistics Views" section. Commit 9868167500 added pg_stat_replication_slots view to monitor ReorderBuffer stats but mistakenly added it under "Dynamic Statistics Views" section in the docs whereas it belongs to "Collected Statistics Views" section. Author: Amit Kapila Reviewed-by: Masahiko Sawada Backpatch-through: 14, where it was introduced Discussion: https://postgr.es/m/CAA4eK1Kb5ur=oc-g4casqpojove+s8lnw1wmuy8owasjk8o...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8de4a31720c2c2ce55f73f4af4b3cdc6cdcca225 Modified Files -- doc/src/sgml/monitoring.sgml | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-)
