| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Mithun Cy <mithun(dot)cy(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: DROP OWNED CASCADE vs Temp tables |
| Date: | 2020-01-14 21:59:42 |
| Message-ID: | 20200114215942.GA18482@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On 2020-Jan-13, Tom Lane wrote:
> That seems fundamentally wrong. By the time we've queued an object for
> deletion in dependency.c, we have a lock on it, and we've verified that
> the object is still there (cf. systable_recheck_tuple calls).
> If shdepDropOwned is doing it differently, I'd say shdepDropOwned is
> doing it wrong.
Hmm, it seems to be doing it differently. Maybe it should be acquiring
locks on all objects in that nested loop and verified them for
existence, so that when it calls performMultipleDeletions the objects
are already locked, as you say.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-01-15 01:39:03 | Re: REINDEX CONCURRENTLY unexpectedly fails |
| Previous Message | Alvaro Herrera | 2020-01-14 21:56:17 | Re: libpq parameter parsing problem |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2020-01-14 22:01:00 | Re: Setting min/max TLS protocol in clientside libpq |
| Previous Message | Alvaro Herrera | 2020-01-14 21:53:02 | Re: aggregate crash |