Re: BF animal dikkop reported a failure in 035_standby_logical_decoding

"Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> writes:
> On 5/26/23 9:27 AM, Yu Shi (Fujitsu) wrote:
>> Is it possible that the vacuum command didn't remove tuples and then the
>> conflict was not triggered?

> The flush_wal table added by Andres should guarantee that the WAL is flushed, so
> the only reason I can think about is indeed that the vacuum did not remove tuples (
> but I don't get why/how that could be the case).

This test is broken on its face:

CREATE TABLE conflict_test(x integer, y text);
DROP TABLE conflict_test;
VACUUM full pg_class;

There will be something VACUUM can remove only if there were no other
transactions holding back global xmin --- and there's not even a delay
here to give any such transaction a chance to finish.

Background autovacuum is the most likely suspect for breaking that,
but I wouldn't be surprised if something in the logical replication
mechanism itself could be running a transaction at the wrong instant.

Some of the other recovery tests set
autovacuum = off
to try to control such problems, but I'm not sure how much of
a solution that really is.

regards, tom lane