On Thu, Aug 04, 2022 at 09:24:24AM +1200, Thomas Munro wrote:
> On Thu, Aug 4, 2022 at 3:30 AM Justin Pryzby wrote:
> > On Thu, Dec 09, 2021 at 12:10:23PM +1300, Thomas Munro wrote:
> > > This adds 2 whole minutes to the recovery check, when running with the
> > > Windows serial-only scripts on
On Thu, Aug 4, 2022 at 3:30 AM Justin Pryzby wrote:
> On Thu, Dec 09, 2021 at 12:10:23PM +1300, Thomas Munro wrote:
> > This adds 2 whole minutes to the recovery check, when running with the
> > Windows serial-only scripts on Cirrus CI (using Andres's CI patches).
> > For Linux it adds ~20
On Thu, Dec 09, 2021 at 12:10:23PM +1300, Thomas Munro wrote:
> This adds 2 whole minutes to the recovery check, when running with the
> Windows serial-only scripts on Cirrus CI (using Andres's CI patches).
> For Linux it adds ~20 seconds to the total of -j8 check-world.
> Hopefully that's time
I wrote:
> I think the fundamental instability here is that this TAP test is
> setting shared_buffers small enough to allow the syncscan logic
> to kick in where it does not in normal testing. Maybe we should
> just disable syncscan in this test script?
Did that, we'll see how much it helps.
Thomas Munro writes:
> cfbot found another source of nondeterminism in the regression tests,
> due to the smaller shared_buffers used in this TAP test:
This failure seems related but not identical:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=myna=2022-04-02%2004%3A00%3A26
cfbot found another source of nondeterminism in the regression tests,
due to the smaller shared_buffers used in this TAP test:
https://cirrus-ci.com/task/4611828654276608
https://api.cirrus-ci.com/v1/artifact/task/4611828654276608/log/src/test/recovery/tmp_check/regression.diffs
Turned out that
On Thu, Mar 24, 2022 at 9:16 PM Andres Freund wrote:
> > VACUUM FREEZE (without DISABLE_PAGE_SKIPPING) seems like it would do
> > everything you want, without using a temp table. At least on the
> > master branch.
>
> We tried that in a prior case:
>
On Fri, Mar 25, 2022 at 5:16 PM Andres Freund wrote:
> On 2022-03-24 21:06:21 -0700, Peter Geoghegan wrote:
> > VACUUM FREEZE (without DISABLE_PAGE_SKIPPING) seems like it would do
> > everything you want, without using a temp table. At least on the
> > master branch.
>
> We tried that in a prior
Hi,
On 2022-03-24 21:06:21 -0700, Peter Geoghegan wrote:
> On Thu, Mar 24, 2022 at 8:56 PM Thomas Munro wrote:
> > Interesting. IIUC your chaos gizmo shows that particular vacuum test
> > still failing on master, but that wouldn't happen in real life because
> > since 383f2221 it's a temp
On Thu, Mar 24, 2022 at 8:56 PM Thomas Munro wrote:
> Interesting. IIUC your chaos gizmo shows that particular vacuum test
> still failing on master, but that wouldn't happen in real life because
> since 383f2221 it's a temp table. Your gizmo should probably detect
> temp rels, as your comment
On Fri, Mar 25, 2022 at 4:03 PM Peter Geoghegan wrote:
> If you want to know whether or not the buildfarm will have problems
> due to VACUUM failing to get a cleanup lock randomly, then I suggest
> that you use an approach like the one from my patch here:
>
>
On Mon, Mar 21, 2022 at 8:59 PM Thomas Munro wrote:
> Thanks. Ahh, déjà vu... this probably needs the same treatment as
> b700f96c and 3414099c provided for the reloptions test. Well, at
> least the first one. Here's a patch like that.
If you want to know whether or not the buildfarm will
On Tue, Mar 22, 2022 at 4:31 PM Masahiko Sawada wrote:
> SELECT pg_relation_size('vac_truncate_test') = 0;
> ?column?
> --
> - t
> + f
Thanks. Ahh, déjà vu... this probably needs the same treatment as
b700f96c and 3414099c provided for the reloptions test. Well, at
least the first
i,
On Mon, Mar 21, 2022 at 5:45 AM Thomas Munro wrote:
>
> On Mon, Mar 21, 2022 at 2:34 AM Andrew Dunstan wrote:
> > On 3/20/22 05:36, Thomas Munro wrote:
> > > On Sun, Mar 20, 2022 at 5:20 PM Thomas Munro
> > > wrote:
> > >> I'll try to come up with the perl needed to see the
On Mon, Mar 21, 2022 at 2:34 AM Andrew Dunstan wrote:
> On 3/20/22 05:36, Thomas Munro wrote:
> > On Sun, Mar 20, 2022 at 5:20 PM Thomas Munro wrote:
> >> I'll try to come up with the perl needed to see the regression.diffs
> >> next time...
> > Here's my proposed change to achieve that.
>
> I
On 3/20/22 05:36, Thomas Munro wrote:
> On Sun, Mar 20, 2022 at 5:20 PM Thomas Munro wrote:
>> Another failure under 027_stream_regress.pl:
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion=2022-03-16%2005%3A58%3A05
>>
>> vacuum ... FAILED 3463
On Sun, Mar 20, 2022 at 5:20 PM Thomas Munro wrote:
> Another failure under 027_stream_regress.pl:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion=2022-03-16%2005%3A58%3A05
>
> vacuum ... FAILED 3463 ms
>
> I'll try to come up with the perl needed
Another failure under 027_stream_regress.pl:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion=2022-03-16%2005%3A58%3A05
vacuum ... FAILED 3463 ms
I'll try to come up with the perl needed to see the regression.diffs
next time...
On Wed, Feb 2, 2022 at 3:43 PM Tom Lane wrote:
> Thomas Munro writes:
> > Seen again today on prairiedog. Erm, scratch that idea, HS feedback
> > interferes with test results. I guess max_standby_streaming_delay
> > should be increased to 'forever', like in the attached, since pg_dump
> > runs
Thomas Munro writes:
> Seen again today on prairiedog. Erm, scratch that idea, HS feedback
> interferes with test results. I guess max_standby_streaming_delay
> should be increased to 'forever', like in the attached, since pg_dump
> runs for a very long time on prairiedog:
FWIW, I'd vote for
Andres Freund writes:
> It's not surprising that pg_dump takes 30s on that old a machine. But more
> than 2min still surprised me. Is that really do be expected?
In the previous buildfarm run, that dump took just under 31s:
2022-01-31 14:21:10.358 EST [19325:1] [unknown] LOG: connection
Hi,
On February 1, 2022 6:11:24 PM PST, Tom Lane wrote:
>Thomas Munro writes:
>> It looks like it's processing statements fairly consistently slowly
>> through the whole period. Each non-trivial statement takes a bit
>> under ~10ms, so it would make sense if by the time we've processed
>>
Thomas Munro writes:
> It looks like it's processing statements fairly consistently slowly
> through the whole period. Each non-trivial statement takes a bit
> under ~10ms, so it would make sense if by the time we've processed
> ~2.5k lines we've clocked up 30 seconds and a VACUUM replay whacks
On Wed, Feb 2, 2022 at 2:14 PM Andres Freund wrote:
> On 2022-02-02 13:59:56 +1300, Thomas Munro wrote:
> > 2022-02-01 04:47:59.294 EST [3670:15] 027_stream_regress.pl LOG:
> > statement: SET TRANSACTION ISOLATION LEVEL REPEATABLE READ, READ ONLY
> > ...
> > 2022-02-01 04:49:09.881 EST
Hi,
On 2022-02-02 13:59:56 +1300, Thomas Munro wrote:
> Seen again today on prairiedog. Erm, scratch that idea, HS feedback
> interferes with test results.
It'd not be sufficient anyway, I think. E.g. autovacuum truncating a table
would not be prevented by hs_f I think?
> I guess
On Sat, Jan 22, 2022 at 6:00 PM Thomas Munro wrote:
> On Sat, Jan 22, 2022 at 8:48 AM Andres Freund wrote:
> > Unfortunately we don't quite seem there yet:
>
> And another way to fail:
>
> pg_dump: error: query failed: ERROR: canceling statement due to
> conflict with recovery
>
>
On 1/27/22 18:24, Thomas Munro wrote:
> On Fri, Jan 28, 2022 at 12:03 PM Andres Freund wrote:
>> Revert "graceful shutdown" changes for Windows, in back branches only.
> FTR I'm actively working on a fix for that one for master now (see
> that other thread where the POC survived Alexander's
On Fri, Jan 28, 2022 at 12:03 PM Andres Freund wrote:
> Revert "graceful shutdown" changes for Windows, in back branches only.
FTR I'm actively working on a fix for that one for master now (see
that other thread where the POC survived Alexander's torture testing).
Hi,
On 2022-01-27 17:51:52 -0500, Andrew Dunstan wrote:
> (Not actually fairywren, but equivalent) It's hung at
> src/test/recovery/t/009_twophase.pl line 84:
>
>
> $psql_rc = $cur_primary->psql('postgres', "COMMIT PREPARED
> 'xact_009_1'");
That very likely is the socket-shutdown bug
Hi,
On 2022-01-27 14:36:32 -0800, Andres Freund wrote:
> > On my windows test instance where I noticed this (w10,
> > msys2/ucrt), check took 516s and this test took 685s.
>
> Hm. That's both excruciatingly slow. Way way slower than what I see here, also
> w10, msys2/ucrt. Any chance the test
On 1/27/22 15:47, Andres Freund wrote:
> Hi,
>
> On 2022-01-27 15:27:17 -0500, Andrew Dunstan wrote:
>> fairywren is not happy with the recovery tests still.
> Any more details?
(Not actually fairywren, but equivalent) It's hung at
src/test/recovery/t/009_twophase.pl line 84:
$psql_rc =
Hi,
On 2022-01-27 17:16:17 -0500, Andrew Dunstan wrote:
> On crake (slowish fedora 34), a normal check run took 95s, and this test
> took 114s.
That's roughly what I see on msys after the fix.
> On my windows test instance where I noticed this (w10,
> msys2/ucrt), check took 516s and this test
On Fri, Jan 28, 2022 at 11:03 AM Andres Freund wrote:
> That means every single psql started by 027_stream_regress.pl's pg_regress
> takes 2s. Which of course adds up...
That is very surprising, thanks. Will fix.
I've been experimenting with reusing psql sessions and backends for
queries in
On 1/27/22 15:47, Andres Freund wrote:
> Hi,
>
> On 2022-01-27 15:27:17 -0500, Andrew Dunstan wrote:
>> fairywren is not happy with the recovery tests still.
> Any more details?
I'll go back and get some.
>
>
>> I have noticed on a different setup that this test adds 11 minutes to the
>>
On 2022-01-27 14:03:51 -0800, Andres Freund wrote:
> In my msys install a normal regress run takes 57s, 027_stream_regress.pl takes
> 194s.
>
> That means every single psql started by 027_stream_regress.pl's pg_regress
> takes 2s. Which of course adds up...
Oh, forgot: After adding --host to the
Hi,
On 2022-01-27 12:47:08 -0800, Andres Freund wrote:
> > I have noticed on a different setup that this test adds 11 minutes to the
> > runtime of the recovery tests, effectively doubling it. The doubling is
> > roughly true on faster setups, too
>
> Does a normal regress run take roughly that
On Fri, Jan 28, 2022 at 9:27 AM Andrew Dunstan wrote:
> I have noticed on a different setup that this test adds 11 minutes to
> the runtime of the recovery tests, effectively doubling it. The doubling
> is roughly true on faster setups, too. At least I would like a simple
> way to disable the
Hi,
On 2022-01-27 15:27:17 -0500, Andrew Dunstan wrote:
> fairywren is not happy with the recovery tests still.
Any more details?
> I have noticed on a different setup that this test adds 11 minutes to the
> runtime of the recovery tests, effectively doubling it. The doubling is
> roughly true
On 1/21/22 16:22, Andrew Dunstan wrote:
> On 1/21/22 13:58, Thomas Munro wrote:
>> On Fri, Jan 21, 2022 at 3:42 PM Thomas Munro wrote:
>>> Thanks. I added that and pushed. Let's see if fairywren likes it
>>> when it comes back online.
>> A watched pot never boils, but I wonder why Andrew's 4
On Sat, Jan 22, 2022 at 8:48 AM Andres Freund wrote:
> Unfortunately we don't quite seem there yet:
And another way to fail:
pg_dump: error: query failed: ERROR: canceling statement due to
conflict with recovery
On 1/21/22 13:58, Thomas Munro wrote:
> On Fri, Jan 21, 2022 at 3:42 PM Thomas Munro wrote:
>> Thanks. I added that and pushed. Let's see if fairywren likes it
>> when it comes back online.
> A watched pot never boils, but I wonder why Andrew's 4 Windows
> configurations jacana, bowerbird,
On Sat, Jan 22, 2022 at 8:48 AM Andres Freund wrote:
> Unfortunately we don't quite seem there yet:
>
> I saw a couple failures like:
> https://api.cirrus-ci.com/v1/artifact/task/5394938773897216/regress_diffs/build/testrun/recovery/t/027_stream_regress/regression.diffs
> (from
Hi,
On 2022-01-17 17:25:19 +1300, Thomas Munro wrote:
> I reordered the arguments, tested locally under the buildfarm client script,
> and pushed. I'll keep an eye on the build farm.
After the reloptions fix the tests seem much more likely to succeed than
before. Progress!
Unfortunately we
On Fri, Jan 21, 2022 at 3:42 PM Thomas Munro wrote:
> Thanks. I added that and pushed. Let's see if fairywren likes it
> when it comes back online.
A watched pot never boils, but I wonder why Andrew's 4 Windows
configurations jacana, bowerbird, fairywren and drongo have stopped
returning
On Mon, Jan 17, 2022 at 6:53 PM Noah Misch wrote:
> On Mon, Jan 17, 2022 at 05:25:19PM +1300, Thomas Munro wrote:
> > Here's how it failed on fairywren, in case someone knowledgeable of
> > MSYS path translation etc can spot the problem:
> You likely need a PostgreSQL::Test::Utils::perl2host()
On Mon, Jan 17, 2022 at 05:25:19PM +1300, Thomas Munro wrote:
> Here's how it failed on fairywren, in case someone knowledgeable of
> MSYS path translation etc can spot the problem:
>
> psql::1: ERROR: directory
>
On Sat, Jan 15, 2022 at 12:49 PM Andres Freund wrote:
> On 2022-01-15 02:32:35 +1300, Thomas Munro wrote:
> > 1. The way I invoke pg_regress doesn't seem to work correctly under
> > the build farm client (though it works fine under make), not sure why
> > yet, but reproduced here and will figure
Hi,
On 2022-01-15 02:32:35 +1300, Thomas Munro wrote:
> 1. The way I invoke pg_regress doesn't seem to work correctly under
> the build farm client (though it works fine under make), not sure why
> yet, but reproduced here and will figure it out tomorrow.
I think it's just a problem of the
On Sat, Jan 15, 2022 at 12:39 AM Thomas Munro wrote:
> On Wed, Dec 22, 2021 at 11:41 AM Thomas Munro wrote:
> > Rebased and updated based on feedback. Responses to multiple emails below:
>
> Pushed, but the build farm doesn't like it with a couple of different
> ways of failing. I'll collect
On Wed, Dec 22, 2021 at 11:41 AM Thomas Munro wrote:
> Rebased and updated based on feedback. Responses to multiple emails below:
Pushed, but the build farm doesn't like it with a couple of different
ways of failing. I'll collect some results and revert shortly.
"SET allow_in_place_tablespaces=on; CREATE TABLESPACE regress_ts4 LOCATION ''");
+ok($result == 0, 'create tablespace 4 with in-place directory');
+
+# Create a table and test moving between absolute and in-place tablespaces
+$result = $node->psql('postgres',
+ "CREATE TABLE t ()
On Wed, Dec 15, 2021 at 05:50:45PM +0900, Michael Paquier wrote:
> Hmm. FWIW, I am working on doing similar for pg_upgrade to switch to
> TAP there, and we share a lot in terms of running pg_regress on an
> exising cluster. Wouldn't it be better to move this definition to
>
On Fri, Dec 10, 2021 at 12:58:01PM +1300, Thomas Munro wrote:
> -# required for 017_shm.pl
> +# required for 017_shm.pl and 027_stream_regress.pl
> REGRESS_SHLIB=$(abs_top_builddir)/src/test/regress/regress$(DLSUFFIX)
> export REGRESS_SHLIB
Hmm. FWIW, I am working on doing similar for
Hi,
On 2021-12-10 12:58:01 +1300, Thomas Munro wrote:
> > What's the relation of this to the rest?
>
> Someone decided that allow_streaming should imply max_connections =
> 10, but we need ~20 to run the parallel regression test schedule.
> However, I can just as easily move that to a local
On 12/9/21 15:15, Thomas Munro wrote:
> On Fri, Dec 10, 2021 at 2:12 AM Andrew Dunstan wrote:
>> The new version appears to set an empty --bindir for pg_regress. Is that
>> right?
> It seems to be necessary to find eg psql, since --bindir='' means
> "expect $PATH to contain the installed
On Fri, Dec 10, 2021 at 12:58 PM Thomas Munro wrote:
> +$node_primary->adjust_conf('postgresql.conf', 'max_connections', '25', 1);
Erm, in fact this requirement came about in an earlier version where I
was invoking make and getting --max-concurrent-tests=20 from
src/test/regress/GNUmakefile.
CREATE TABLESPACE regress_tablespace LOCATION '$LOCATION'");
+ok($result != 0, 'clobber tablespace with absolute path');
+
+# Create table in it
+$result = $node->psql('postgres',
+ "CREATE TABLE t () TABLESPACE regress_tablespace");
+ok($result == 0, 'create table in tables
Hi,
On 2021-12-09 12:10:23 +1300, Thomas Munro wrote:
> From a60ada37f3ff7d311d56fe453b2abeadf0b350e5 Mon Sep 17 00:00:00 2001
> From: Thomas Munro
> Date: Wed, 4 Aug 2021 22:17:54 +1200
> Subject: [PATCH v8 2/5] Use relative paths for tablespace regression test.
>
> Remove the machinery from
On Fri, Dec 10, 2021 at 8:38 AM Andres Freund wrote:
> On 2021-12-09 08:12:14 -0500, Andrew Dunstan wrote:
> > > Does anyone want to object to the concept of the "pg_user_files"
> > > directory or the developer-only GUC "allow_relative_tablespaces"?
> > > There's room for discussion about names;
On Fri, Dec 10, 2021 at 2:12 AM Andrew Dunstan wrote:
> The new version appears to set an empty --bindir for pg_regress. Is that
> right?
It seems to be necessary to find eg psql, since --bindir='' means
"expect $PATH to contain the installed binaries", and that's working
on both build systems.
Hi,
On 2021-12-09 08:12:14 -0500, Andrew Dunstan wrote:
> > Does anyone want to object to the concept of the "pg_user_files"
> > directory or the developer-only GUC "allow_relative_tablespaces"?
> > There's room for discussion about names; maybe initdb shouldn't create
> > the directory unless
On 12/8/21 18:10, Thomas Munro wrote:
> On Sun, Dec 5, 2021 at 4:16 AM Andrew Dunstan wrote:
>> TAP tests are passed a path to pg_regress as $ENV{PG_REGRESS}. You
>> should be using that. On non-MSVC, the path to a non-installed psql is
>> in this case "$TESTDIR/../../bin/psql" - this should
TER TABLESPACE regress_tblspace SET (random_page_cost = 1.0, seq_page_cost = 1.1);
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 5975e7c9cd..bf66083f73 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -133,7 +133,6 @@ sub installcheck_int
On 12/3/21 23:21, Thomas Munro wrote:
>
> Next problem: The below is clearly not the right way to find the
> pg_regress binary and bindir, and doesn't work on Windows or VPATH.
> Any suggestions for how to do this? I feel like something like
> $node->installed_command() or similar logic is
egress_tblspace SET (random_page_cost = 1.0, seq_page_cost = 1.1);
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index f3357b3292..92debf9b0f 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -118,7 +118,6 @@ sub installcheck_internal
&quo
On 11/23/21 10:47, Andrew Dunstan wrote:
> On 11/23/21 04:07, Thomas Munro wrote:
>> On Wed, Oct 6, 2021 at 7:10 PM Thomas Munro wrote:
>>> I wonder if for Windows we'd want to switch to real symlinks, since,
>>> as far as I know from some light reading, reparse points are converted
>>> to
On 11/23/21 04:07, Thomas Munro wrote:
> On Wed, Oct 6, 2021 at 7:10 PM Thomas Munro wrote:
>> I wonder if for Windows we'd want to switch to real symlinks, since,
>> as far as I know from some light reading, reparse points are converted
>> to absolute paths on creation, so the pgdata directory
cregress.pl b/src/tools/msvc/vcregress.pl
index f3357b3292..92debf9b0f 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -118,7 +118,6 @@ sub installcheck_internal
"--bindir=../../../$Config/psql",
"--schedule=${schedule}_schedule",
"--max-concurrent-tests=20
er can do it easily. Better syntax welcome.
(I originally wanted to use WITH () but that syntax is
tangled up with persistent relopts.)
0003: Use relative paths for tablespace regression test.
Remove the pg_regress logic for creating the directory, and switch to
relative paths using the above.
0004: Test
On Thu, Jun 10, 2021 at 7:37 PM Anastasia Lubennikova
wrote:
> вт, 8 июн. 2021 г. в 02:44, Anastasia Lubennikova :
>> Thank you for working on this test set!
>> I was especially glad to see the skip-tests option for pg_regress. I think
>> it will become a very handy tool for hackers.
>>
>> To
вт, 8 июн. 2021 г. в 02:44, Anastasia Lubennikova :
>
> вт, 8 июн. 2021 г. в 02:25, Thomas Munro :
>
>> Ok, here's a new version incorporating feedback so far.
>>
>> 1. Invoke pg_regress directly (no make).
>>
>> 2. Use PG_TEST_EXTRA="wal_consistency_checking" as a way to opt in to
>> the more
вт, 8 июн. 2021 г. в 02:25, Thomas Munro :
> Ok, here's a new version incorporating feedback so far.
>
> 1. Invoke pg_regress directly (no make).
>
> 2. Use PG_TEST_EXTRA="wal_consistency_checking" as a way to opt in to
> the more expensive test.
>
> 3. Use parallel schedule rather than
.pl).
From c14c839be91b4b7b534c899370a5f450f118fed3 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Fri, 23 Apr 2021 15:37:09 +1200
Subject: [PATCH v2] Test replay of regression tests.
Add a new TAP test under src/test/recovery to run the standard
regression tests with a streaming replica replaying the WAL. This
provid
Hi,
On 2021-04-23 13:13:15 -0400, Tom Lane wrote:
> contrib/bloom is indeed the only(?) case within contrib, but in my mind
> that's a proxy for what people will be needing to test out-of-core AMs.
> It might not be a test to run by default, but there needs to be a way
> to do it.
Hm. My
Andres Freund writes:
> On 2021-04-23 11:53:35 -0400, Tom Lane wrote:
>> Yeah. I found out earlier that wal_consistency_checking=all is an
>> absolute PIG. Running the regression tests that way requires tens of
>> gigabytes of disk space, and a significant amount of time if your
>> disk is not
Hi,
On 2021-04-23 11:53:35 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Hm. I wonder if running with wal_consistency_checking=all doesn't also
> > reduce coverage of some aspects of recovery, by increasing record sizes
> > etc.
>
> Yeah. I found out earlier that
Andres Freund writes:
> On 2021-04-23 17:37:48 +1200, Thomas Munro wrote:
>> We have automated tests for many specific replication and recovery
>> scenarios, but nothing that tests replay of a wide range of records.
> Yay.
+1
>> Add a new TAP test under src/test/recovery that runs the
On 4/23/21 1:37 AM, Thomas Munro wrote:
> Hi,
>
> We have automated tests for many specific replication and recovery
> scenarios, but nothing that tests replay of a wide range of records.
> People working on recovery code often use installcheck (presumably
> along with other custom tests) to
Hi,
On 2021-04-23 17:37:48 +1200, Thomas Munro wrote:
> We have automated tests for many specific replication and recovery
> scenarios, but nothing that tests replay of a wide range of records.
> People working on recovery code often use installcheck (presumably
> along with other custom tests)
On Fri, Apr 23, 2021 at 6:27 PM tsunakawa.ta...@fujitsu.com
wrote:
> From: Thomas Munro
> > I'm not quite sure where it belongs, though. The attached initial sketch
> > patch
>
> I think that's a good attempt. It'd be better to confirm that the database
> contents are identical on the
From: Thomas Munro
> We have automated tests for many specific replication and recovery scenarios,
> but nothing that tests replay of a wide range of records.
> People working on recovery code often use installcheck (presumably along
> with other custom tests) to exercise it, sometimes with
>
come.
From f7d199cefdec98bcdc5f580e5175ce09cb1299b2 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Fri, 23 Apr 2021 15:37:09 +1200
Subject: [PATCH] Test replay of regression tests.
Add a new TAP test under src/test/recovery that runs the regression
tests with wal_consistency_checking=all.
---
src/test/recover
82 matches
Mail list logo
