> Hi, I have also reported a similar problem in the hackers mailing list,
but particularly on TRUNCATE TABLE.
https://www.postgresql.org/message-id/flat/D09B13F772D2274BB348A310EE3027C62FD6E6%40g01jpexmbkw24
Ooh, interesting. I admit I did not include TRUNCATE in my testing.
> The problem lies wi
> There was a recent commit for a similar performance problem, which will
appear in 9.6.10. But that was specifically for cases where there were
multiple dropped tables per transaction, and large shared_buffers.
Interesting, and good to know, thanks! I'm not sure we fall under either
(is 8 GB lar
...@postgresql.org
Subject: Slow WAL recovery for DROP TABLE
We are running Postgres 9.6.9 on RHEL 6.9. We're using built-in streaming
replication, with a WAL archive for fallback purposes. No logical replication.
We recently had a bug in our code accidentally create several hundred thousand
tables in a s
There was a recent commit for a similar performance problem, which will
appear in 9.6.10. But that was specifically for cases where there were
multiple dropped tables per transaction, and large shared_buffers.
I can't reproduce your single-drop-per-transaction problem. The replica
has no problem
We are running Postgres 9.6.9 on RHEL 6.9. We're using built-in streaming
replication, with a WAL archive for fallback purposes. No logical
replication.
We recently had a bug in our code accidentally create several hundred
thousand tables in a single database. A batch job started cleaning them up
