Hi,
On 2022-01-31 16:11:15 +0000, PG Bug reporting form wrote:
> We've noticed that at least since 9.5, running pg_repack causes a race
> conditions on our streaming replicas, but _not_ on the primary where
> pg_repack is running. This manifests itself as a client briefly unable to
> open the relation getting repacked - but, in our testing and experience,
> only on the replica.
pg_repack is not part of postgres, so you're going to have to report this to
the developers of pg_repack.
> I would blame pg_repack - its whole purpose for being
> is to transparently remake tables, and quite possibly it got some of the
> details wrong - except that if its behavior appears atomic to clients on the
> primary, then surely it should on the replicas too?
pg_repack modifies catalogs in an unsupported way, so it's not surprising
you'd see some odd effects. Postgres locking and visibility logic doesn't know
about what pg_repack is doing, so it can't enforce correct semantics. I'd
assume that the repack developers haven't gotten the locking logic quite right
someplace.
Greetings,
Andres Freund
