From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | michael(at)paquier(dot)xyz |
Cc: | mahi6run(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema |
Date: | 2019-12-25 03:18:26 |
Message-ID: | 20191225.121826.1424647210525092235.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
At Wed, 25 Dec 2019 11:22:03 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> Anyway, as dropping a temporary schema leads to an inconsistent
> behavior when recreating new temporary objects in a session that
> dropped it, that nobody has actually complained on the matter, and
> that in concept a temporary schema is linked to the session that
Agreed.
> created it, I think that we have a lot of arguments to just forbid the
> operation from happening. Please note as well that it is possible to
> drop temporary schemas of other sessions, still this is limited to
> owners of the schema.
>
> In short, let's tighten the logic, and we had better back-patch this
> one all the way down, 9.4 being broken. Attached is a patch to do
> that. The error message generated depends on the state of the session
> so I have not added a test for this reason, and the check is added
> before the ACL check. We could make the error message more generic,
> like "cannot drop temporary namespace". Any thoughts?
Just inhibiting the action seems reasonable to me.
Still the owner can drop temporary namespace on another session or
pg_toast_temp_x of the current session.
isTempnamespace(address.objectId) doesn't work for the purpose.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-12-25 03:24:10 | Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema |
Previous Message | Michael Paquier | 2019-12-25 02:22:03 | Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2019-12-25 03:19:04 | table partition and column default |
Previous Message | Michael Paquier | 2019-12-25 02:31:27 | Re: Server crash with Master-Slave configuration. |