From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: removal of dangling temp tables
Date: Fri, 14 Dec 2018 23:02:20 -0300
Message-ID: <20181215020220.xk7j2trqbqtqmtdc@alvherre.pgsql> (raw)
In-Reply-To: <CA+TgmobVaOiPKdPB8Rk0P5JJY9+WfGqVn0XK+DS5sdH-dVgH+A@mail.gmail.com>
On 2018-Dec-14, Robert Haas wrote:
> On Fri, Dec 14, 2018 at 12:27 PM Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > Maybe it'd be better to change temp table removal to always drop
> > max_locks_per_transaction objects at a time (ie. commit/start a new
> > transaction every so many objects).
>
> We're basically just doing DROP SCHEMA ... CASCADE, so I'm not sure
> how we'd implement that, but I agree it would be significantly better.
(Minor nit: even currently, we don't drop the schema itself, only the
objects it contains.)
I was thinking we could scan pg_depend for objects depending on the
schema, add them to an ObjectAddresses array, and do
performMultipleDeletions once every max_locks_per_transaction objects.
But in order for this to have any useful effect we'd have to commit the
transaction and start another one; maybe that's too onerous.
Maybe we could offer such a behavior as a special case to be used only
in case the regular mechanism fails. So add a PG_TRY which, in case of
failure, sends a hint to do the cleanup. Not sure this is worthwhile.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, robertmhaas@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: removal of dangling temp tables
In-Reply-To: <20181215020220.xk7j2trqbqtqmtdc@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox