| From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
|---|---|
| To: | Dominique Devienne <ddevienne(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory |
| Date: | 2022-01-10 22:13:13 |
| Message-ID: | dd38f185-53c1-09c6-a915-005a3b443d67@aklaver.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(dot)klaver(at)aklaver(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-01-11 01:02:18 | Re: md5 issues Postgres14 on OL7 |
| Previous Message | Dominique Devienne | 2022-01-10 21:58:42 | Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory |