Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory

From: Dominique Devienne <ddevienne(at)gmail(dot)com>
To: Francisco Olarte <folarte(at)peoplecall(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(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-11 10:57:00
Message-ID: CAFCRh-8a6xDcLaYweaVpoco_CkkYrtZ7x9icPrgGJK0Z=VJq-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Jan 11, 2022 at 11:05 AM Francisco Olarte <folarte(at)peoplecall(dot)com>
wrote:

> Dominique:
> Not going to enter into the lock situation but...
>

OK :). But it does matter. those locks. Especially if DROP'ing a DB (as you
suggest) requires just the same.

> On Tue, 11 Jan 2022 at 10:24, Dominique Devienne <ddevienne(at)gmail(dot)com>
> wrote:
> ...
> > I need for unit testing purposes to be able to support multiple (2+N
> schemas) "instances".
> > Each instance (of 2+N schemas) is owned by a separate ROLE, created for
> that express purpose.
> > I designed / coded it to be able to have several "instances" per DB,
> that come and go for unit testing purpose,
> > and they will come and go concurrently (when CI kicks in, on several
> platforms/configurations in parallel).
> > And I thought DROP OWNED BY was going to be convenient (fewer
> client-server round-trips, perfectly models the *intent*).
> > But obviously given the limitations I'm discovering, that's not the case.
> >
> > In production, there will typically be a single "instance" per DB.
> >
> > So, should I redesign for each instance to be in its own DB? And instead
> of just creating schemas on the fly when running tests, creating DBs on the
> fly?
> > That means I'd could then DROP the whole DB (I wish for DB-specific
> ROLEs BTW...). Does that buy me anything? Does that help with locks-per-tx
> at all?
> > I'm happy to do that, if necessary. But is using a dedicated DB per 2+N
> schemas "instance" the right approach?
>
> I'm not sure if you are going to hit other limitations, but I've
> normally done tests with the "template database" approach ( using
> create database template=, dropping the DB at the end ). It is fast,
> it is simple, it is easy. Have you tried that?

No, I haven't. I did see that feature, in the doc, and wondered about it
for Production, but not for testing.

> seems much easier/faster than building and dropping all this
> schemas/roles,specially for testing.
>

Good to here. But when you write "I've done tests", do you mean manual
tests?
Or automated unit-tests that create DBs (from a template) on-the-fly and
DROP them?
Concurrently from different CI agents?

The reason I didn't consider DB templates for unit-testing, is that the
schemas are changing often.
And creating the schemas is all automated in code already.

Plus ROLEs are CLUSTER-wide, so the DB template does nothing to help with
SCHEMA-associated roles. --DD

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Wolfgang Walther 2022-01-11 11:47:56 Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory
Previous Message Francisco Olarte 2022-01-11 10:04:56 Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory