Re: Found xmin before relfrozenxid and logical replication

On Wed, 18 Aug 2021 at 20:27, J T <jorge(dot)torralba(at)gmail(dot)com> wrote:

>
> The secondary server i create the schema with a pg_dump using the -c
> option. No other databases are on the target since it's a fresh build and
> new install. I create a subscription to the publisher on the primary and
> all is fine while data is initialized. Eventually all is caught up.
>
>
relevant discussion
PostgreSQL: Re: MultiXactId Error in Autovacuum
<https://www.postgresql.org/message-id/CA%2BMJ4cTMTDKZa5P%3DrGbPiK0O0tv2xxpH7_Zopmi1Av0z61UUYw%40mail.gmail.com>
and the relevant fix was in PostgreSQL: Documentation: 9.3: Release 9.3.2
<https://www.postgresql.org/docs/9.3/release-9-3-2.html>

`Fix multiple bugs in MultiXactId freezing (Andres Freund, Álvaro Herrera)
These bugs could lead to "could not access status of transaction" errors,
or to duplicate or vanishing rows. Users upgrading from releases prior to
9.3.0 are not affected.
The issue can be ameliorated by, after upgrading, vacuuming all tables in
all databases while having vacuum_freeze_table_age set to zero. This will
fix latent corruption but will not be able to fix all pre-existing data
errors.`

> Everything looks normal. But, as I look at my log file for errors on the
> replica, I see hundreds of entries for.
>
> 2021-08-16 23:58:14.496 CDT [32191] ERROR: found xmin 387485 from before
> relfrozenxid 531040
> 2021-08-16 23:58:31.632 CDT [32204] ERROR: MultiXactId 537919489 has not
> been created yet -- apparent wraparound
>
>
>
What is the state of dead tx?
can you check the status of tx id using
select txid_status(<problem txid>);

this is for the pgdevs,
ok, i might be silly talking about this, but I do not have a test setup to
reproduce this.
if the dump is fresh and no other consumer of the db exists, can we run a
pg_resetwal on the db to clean those dangling references ?