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 Ci
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 seconds
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 wel
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&dt=2022-04-02%2004%3A00%3A26
portals
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 w
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:
> https://postgr.es/m/20220120052404.sonrhq3f3qgp
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 table.
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 s
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:
>
> https://postgr.es/m/cah2-wzkib-qcsbmwr
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 hav
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 regression.diffs
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 th
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&dt=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&dt=2022-03-16%2005%3A58%3A05
>
> vacuum ... FAILED 3463 ms
>
> I'll try to come up with the perl neede
Another failure under 027_stream_regress.pl:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=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 ke
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 receiv
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
>> ~2.
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 [3683:2585]
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 max_standby_s
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
>
> https://buildf
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 tha
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 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?
(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 TAP
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
>> run
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 p
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 lo
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 test
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 W
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
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi&dt=2022-01-22%2
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, fai
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 https://cirrus-ci.c
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 don'
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 result
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() ca
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
> "/home/pgrunner/bf/root/HEAD/pgsql.build/src/test/modules/test_misc/tmp_check/t_002
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 i
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 buildf
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 so
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.
Hi,
Rebased and updated based on feedback. Responses to multiple emails below:
On Thu, Dec 16, 2021 at 1:22 PM Michael Paquier wrote:
> 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 w
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
> src/Makefile.global.in
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 pg_upgrad
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 adjus
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 binarie
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. Whi
On Fri, Dec 10, 2021 at 10:36 AM Andres Freund wrote:
> Seems like we ought to add a tiny tap test or such for this - otherwise we
> won't have any coverage of "normal" tablespaces? I don't think they need to be
> exercised as part of the normal tests, but having some very basic testing
> in a tap
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 pg
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; m
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 you
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 wo
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 work for VPATH
> builds as well as non-VPATH. O
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 need
On Tue, Nov 30, 2021 at 3:14 AM Andrew Dunstan wrote:
> choco install -y Carbon
> Import-Module Carbon
> Grant-CPrivilege -Identity myuser -Privilege SeCreateSymbolicLinkPrivilege
Interesting. Well, I found the problem with my last patch (to wit:
junction points must be absolute, unl
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 absol
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
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 would be less
> portable than it would be on P
On Thu, Jun 10, 2021 at 7:47 PM Thomas Munro wrote:
> On Thu, Jun 10, 2021 at 7:37 PM Anastasia Lubennikova
> wrote:
> > For some reason, it failed on cfbot, so I'll switch it back to 'Waiting on
Sorry for the delay. I got stuck in a CI loop trying to make a new
improved version work on Windows
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 try
вт, 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 e
вт, 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 serial.
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 serial. It's faster but also
the non-determinism might discover
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 experien
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 v
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 wal_consistency_checking=a
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 regressio
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 exer
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) to
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 primary
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
> wal_
81 matches
Mail list logo
