Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory - Mailing list pgsql-general

From Adrian Klaver
Subject Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory
Date
Msg-id dd38f185-53c1-09c6-a915-005a3b443d67@aklaver.com
Whole thread Raw
In response to Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory  (Dominique Devienne <ddevienne@gmail.com>)
Responses Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory  (Dominique Devienne <ddevienne@gmail.com>)
List 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 by date:

Previous
From: Dominique Devienne
Date:
Subject: Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory
Next
From: Michael Paquier
Date:
Subject: Re: md5 issues Postgres14 on OL7