Re: Test 031_recovery_conflict.pl is not immune to autovacuum

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Test 031_recovery_conflict.pl is not immune to autovacuum
Date: 2024-03-20 19:24:01
Message-ID: CAAKRu_Z6W9=9iKEUrYfD9Rw8Nuwb9+oxjkqkx-MqoBdtn0q+RA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 20, 2024 at 10:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> Hello Melanie,
>
> 20.03.2024 16:15, Melanie Plageman wrote:
> > Seems like we could just add autovacuum_enabled=false to the table like this:
> > diff --git a/src/test/recovery/t/031_recovery_conflict.pl
> > b/src/test/recovery/t/031_recovery_conflict.pl
> > index d87efa823fd..65bc858c02d 100644
> > --- a/src/test/recovery/t/031_recovery_conflict.pl
> > +++ b/src/test/recovery/t/031_recovery_conflict.pl
> > @@ -59,7 +59,7 @@ my $table1 = "test_recovery_conflict_table1";
> > my $table2 = "test_recovery_conflict_table2";
> > $node_primary->safe_psql(
> > $test_db, qq[
> > -CREATE TABLE ${table1}(a int, b int);
> > +CREATE TABLE ${table1}(a int, b int) WITH (autovacuum_enabled = false);
> > INSERT INTO $table1 SELECT i % 3, 0 FROM generate_series(1,20) i;
> > CREATE TABLE ${table2}(a int, b int);
> > ]);
>
> Thanks for paying attention to it!
>
> With such modification applied I've got another failure (on iteration 2):

Thanks for trying it out!

> [13:27:39.034](2.317s) ok 14 - startup deadlock: lock acquisition is waiting
> Waiting for replication conn standby's replay_lsn to pass 0/343E6D0 on primary
> done
> timed out waiting for match: (?^:User transaction caused buffer deadlock with recovery.) at t/031_recovery_conflict.pl
> line 318.
> # Postmaster PID for node "primary" is 1523036
> ### Stopping node "primary" using mode immediate
>
> 031_recovery_conflict_standby.log really doesn't contain the expected
> message. I can share log files from a successful and failed test runs, if
> they can be helpful, or I'll investigate this case today/tomorrow.

Hmm. The log file from the failed test run with
(autovacuum_enabled=false) would be helpful. I can't tell without the
log if it hit a different type of conflict. Unfortunately it was very
difficult to trigger the specific type of recovery conflict we were
trying to test and not hit another of the recovery conflict types
first. It'll take me some time to swap this back in my head, though.

- Melanie

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2024-03-20 19:26:38 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
Previous Message Nathan Bossart 2024-03-20 19:24:00 Re: cleanup patches for incremental backup