On 2022-Jan-10, Dominique Devienne wrote: > Given max_locks_per_transaction * (max_connections > <https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-MAX-CONNECTIONS> > + max_prepared_transactions > <https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAX-PREPARED-TRANSACTIONS>) > from > https://www.postgresql.org/docs/current/runtime-config-locks.html, and > max_conn being 100, that's not many locks. 6400 locks, to be precise. So if your schemas have on average 10 tables each with 3 indexes per table, you could drop at most 160 schemas in one go (but only if you're lucky.) > Given there's only 64 locks per conn by default, how can this work with > over 100 tables? > I'm confused... --DD That value indicates the maximum number of locks that can be taken across all sessions at a time. You can have a single session take that number of locks, or all sessions take 64 locks each. If you really have many more relations that need to be dropped, you could try to issue "DROP SCHEMA...CASCADE" for each schema to drop. It's a lot less convenient than DROP OWNED BY, but it doesn't require to take as many locks simultaneously. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "Los trabajadores menos efectivos son sistematicamente llevados al lugar donde pueden hacer el menor daño posible: gerencia." (El principio Dilbert)
