Andreas Kretschmer <andreas@xxxxxxxxxxxxxxx> wrote (2023. nov. 24., P, 13:22):
Am 24.11.23 um 12:39 schrieb Les:
>
> Hello,
>
please check the database log, a VACUUM can also lead to massive wal
generation. Can you find other related messages? by the way, the picture
is hard to read, please post text instead of pictures.
First I was also thinking about vacuum. But removing a replication slot should have no effect on vacuum on the primary (AFAIK). Please correct me if I'm wrong. And yet, removing the replication slot solved the problem immediately, including write speed (went down from 1.5GB/sec to 5MB/sec) and pg_wal directory size (PostgreSQL deleted 100G+ files within a few minutes, only a single WAL segment remained in pg_wal). This is not by coincidence. This happened three times, and in all cases, dropping the slot was the only thing that "solved" the problem. Maybe the slot itself was not the direct cause, but it is strongly correlated. Unfortunately, it would be problematic to try this out again. We could only observe the problem on the prod server, never on the dev servers; and we can't play with the prod servers.
I'm sorry about the picture, I did not have this in plain text, only on a screenshot. (I still have the WAL files, but not the full data directory, and I don't know how to examine the pg_wal directory without the containing data directory. pg_waldump requires a PGDATA directory.)
Laszlo
