| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: removal of dangling temp tables |
| Date: | 2018-12-14 17:48:35 |
| Message-ID: | CA+TgmobVaOiPKdPB8Rk0P5JJY9+WfGqVn0XK+DS5sdH-dVgH+A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 14, 2018 at 12:27 PM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Hmm, I think in the case covered by your commit, that is a session that
> crashes with a few thousands of temp tables, this new patch might cause
> a failure to open a new session altogether.
Oh, good point. Or if the catalog is corrupted.
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-12-14 17:57:23 | Re: removal of dangling temp tables |
| Previous Message | Alvaro Herrera | 2018-12-14 17:26:58 | Re: removal of dangling temp tables |