Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory
От | Adrian Klaver |
---|---|
Тема | Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory |
Дата | |
Msg-id | dd38f185-53c1-09c6-a915-005a3b443d67@aklaver.com обсуждение исходный текст |
Ответ на | Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory (Dominique Devienne <ddevienne@gmail.com>) |
Ответы |
Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory
|
Список | pgsql-general |
On 1/10/22 13:58, Dominique Devienne wrote: > > Given that Tom mentions max_locks_per_transaction can be safely increased, > and given the stats I mentioned in this thread, what would a > "reasonable" max_locks_per_transaction > be in my case? By reasonable, I mean "as large as possible w/o being too > large"... > > Obviously 64*100 is not quite large enough to be safe in this case. I'd > appreciate some advise. TIA, --DD I think at this point it might be a good idea to explore what the case is? In your OP the error occurred here: DROP OWNED BY "Epos-PNS (a73e1fbdcc5b4460ba55703a0d6b6ad7)" CASCADE The CASCADE allows to command to recurse to objects that may not be owned by the specified role. Is that what you want? What is the purpose of the process, clearing out given schema, dropping objects only owned by a given role, or something else? -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: