"Drouvot, Bertrand" <bertranddrouvot.pg@gmail.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
