Message-ID: <2e203472-72b5-1b55-377a-824c3f28b190@gmail.com>
Date: Thu, 4 Jan 2024 16:00:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: Add a perl function in Cluster.pm to generate WAL
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>
Cc: Euler Taveira <euler@eulerto.com>,
 Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org
References: <CALj2ACU3R8QFCvDewHCMKjgb2w_-CMCyd6DAK=Jb-af14da5eg@mail.gmail.com>
 <20230615.134015.1421242753635015365.horikyota.ntt@gmail.com>
 <ZIvJN/VVQUn6nb8p@paquier.xyz>
 <CALj2ACUkXXsCTNoqhTr=S-CV7qdCB=QEiMvuuo31brLkLz4o6w@mail.gmail.com>
 <CALj2ACXR7FkdvzK1XaansV05awGnaCH82yu9M4gBiCueU_0GSA@mail.gmail.com>
 <3a6978d6-e4fc-4014-b5f7-45db53d8fa53@app.fastmail.com>
 <ZYEaLlhZ5lgTqsaQ@paquier.xyz>
 <CALj2ACXppTLS1pKa=M-h-VxWHSTo4iJvHYik_J+pLQxdeLMAzQ@mail.gmail.com>
 <ZYIgg55UyDS56Y9l@paquier.xyz>
 <5d160064-8cbe-4b32-9c55-c983b1f63b12@app.fastmail.com>
 <ZYOTKV1MV7gDYpCV@paquier.xyz> <370894.1704325169@sss.pgh.pa.us>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <370894.1704325169@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/2e203472-72b5-1b55-377a-824c3f28b190%40gmail.com>
Precedence: bulk

Hello Tom,

04.01.2024 02:39, Tom Lane wrote:
> Buildfarm member skink has failed 3 times in
> 035_standby_logical_decoding.pl in the last couple of days:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2024-01-03%2020%3A07%3A15
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2024-01-03%2017%3A09%3A27
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2024-01-01%2020%3A10%3A18
>
> These all look like
>
> # poll_query_until timed out executing this query:
> # select (confl_active_logicalslot = 1) from pg_stat_database_conflicts where datname = 'testdb'
> # expecting this output:
> # t
> # last actual query output:
> # f
>
> although it's notable that two different tests are involved
> (vacuum vs. vacuum full).
>
> I am not real sure what is happening there, but I see that c161ab74f
> changed some details of how that test works, so I wonder if it's
> responsible for these failures.  The timing isn't a perfect match,
> since this commit went in two weeks ago, but I don't see any
> more-recent commits that seem like plausible explanations.

Reproduced here.
As I can see in the failure logs you referenced, the first problem is:
#   Failed test 'inactiveslot slot invalidation is logged with vacuum on pg_authid'
#   at t/035_standby_logical_decoding.pl line 224.

It reminded me of:
https://www.postgresql.org/message-id/b2a1f7d0-7629-72c0-2da7-e9c4e336b010%40gmail.com

It seems that it's not something new, and maybe that my analysis is still
valid. If so, VACUUM FREEZE/autovacuum = off should fix the issue.

Best regards,
Alexander