On Tue, Feb 26, 2019 at 07:21:40PM -0500, Tom Lane wrote:
> The existing state of affairs is that a superuser who really needs to drop
> a temp schema can do so, if she's careful that it's not active. Pinning
> things would break that, or at least add an additional roadblock. If it's
> some sort
Alvaro Herrera writes:
> On 2019-Feb-23, Tom Lane wrote:
>> However, if someone held a gun to my head and said fix it, I'd be inclined
>> to do so by having temp-namespace creation insert a "pin" dependency into
>> pg_depend. Arguably, the only reason we don't create all the temp
>> namespaces du
On 2019-Feb-23, Tom Lane wrote:
> However, if someone held a gun to my head and said fix it, I'd be inclined
> to do so by having temp-namespace creation insert a "pin" dependency into
> pg_depend. Arguably, the only reason we don't create all the temp
> namespaces during bootstrap is because we
On Sat, Feb 23, 2019 at 04:29:24PM +0100, Magnus Hagander wrote:
> On Sat, Feb 23, 2019 at 4:18 PM Michael Paquier wrote:
>> Perhaps I am missing something, but it would be just more simple to
>> now allow users to restrict that?
>>
>
> I can't parse what you are saying here. Now allow users to r
On Sat, Feb 23, 2019 at 5:01 PM Tom Lane wrote:
> Magnus Hagander writes:
> > I think we're better off just peventing the explicit drop of a temp
> schema.
> > See attached?
>
> I think this is a poor implementation of a bad idea. Would you like a
> list of the ways a superuser can break the sy
Magnus Hagander writes:
> I think we're better off just peventing the explicit drop of a temp schema.
> See attached?
I think this is a poor implementation of a bad idea. Would you like a
list of the ways a superuser can break the system? We could start with
"DELETE FROM pg_proc;".
Magnus Hagander writes:
> On Fri, Feb 22, 2019 at 7:15 PM Robert Haas wrote:
>> On Fri, Feb 22, 2019 at 1:14 PM Tom Lane wrote:
>>> Note that all the temp schemas are made as owned by the bootstrap
>>> superuser, so there is no real argument to be made that people might
>>> be expecting they sho
On Sat, Feb 23, 2019 at 4:28 PM Magnus Hagander wrote:
>
>
> On Sat, Feb 23, 2019 at 12:29 AM Michael Paquier
> wrote:
>
>> On Fri, Feb 22, 2019 at 09:45:42AM -0500, Tom Lane wrote:
>> > +1 ... maybe "(dropped)", because we tend to use parens for this sort
>> > of thing, I think.
>>
>> +1. Usin
On Sat, Feb 23, 2019 at 4:18 PM Michael Paquier wrote:
> On Sat, Feb 23, 2019 at 02:48:58PM +0100, Magnus Hagander wrote:
> > I think we need to either prevent dropping of temp namespaces *or* we
> need
> > to create a new entry in pg_namespace in this particular case.
>
> Perhaps I am missing so
On Sat, Feb 23, 2019 at 12:29 AM Michael Paquier
wrote:
> On Fri, Feb 22, 2019 at 09:45:42AM -0500, Tom Lane wrote:
> > +1 ... maybe "(dropped)", because we tend to use parens for this sort
> > of thing, I think.
>
> +1. Using "dropped" sounds good to me in this context. Perhaps we
> could have
On Sat, Feb 23, 2019 at 02:48:58PM +0100, Magnus Hagander wrote:
> I think we need to either prevent dropping of temp namespaces *or* we need
> to create a new entry in pg_namespace in this particular case.
Perhaps I am missing something, but it would be just more simple to
now allow users to rest
On Fri, Feb 22, 2019 at 7:15 PM Robert Haas wrote:
> On Fri, Feb 22, 2019 at 1:14 PM Tom Lane wrote:
> > Why? It would likely be a significant amount of effort and added
> overhead,
> > to accomplish no obviously-useful goal.
> >
> > Note that all the temp schemas are made as owned by the boots
On Fri, Feb 22, 2019 at 09:45:42AM -0500, Tom Lane wrote:
> +1 ... maybe "(dropped)", because we tend to use parens for this sort
> of thing, I think.
+1. Using "dropped" sounds good to me in this context. Perhaps we
could have something more fancy like what's used for dropped columns?
It would
On Fri, Feb 22, 2019 at 1:14 PM Tom Lane wrote:
> Why? It would likely be a significant amount of effort and added overhead,
> to accomplish no obviously-useful goal.
>
> Note that all the temp schemas are made as owned by the bootstrap
> superuser, so there is no real argument to be made that pe
Robert Haas writes:
> On Fri, Feb 22, 2019 at 12:54 PM Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Feb 22, 2019 at 3:43 AM Magnus Hagander wrote:
We are certainly not supposed to go DROP SCHEMA on the temp namespaces, ...
>>> Actually, I think that's supposed to work.
>> If it's i
On Fri, Feb 22, 2019 at 12:54 PM Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Feb 22, 2019 at 3:43 AM Magnus Hagander wrote:
> >> We are certainly not supposed to go DROP SCHEMA on the temp namespaces, ...
>
> > Actually, I think that's supposed to work.
>
> If it's in active use by any ses
Robert Haas writes:
> On Fri, Feb 22, 2019 at 3:43 AM Magnus Hagander wrote:
>> We are certainly not supposed to go DROP SCHEMA on the temp namespaces, ...
> Actually, I think that's supposed to work.
If it's in active use by any session (including your own), that's not going
to have nice conse
On Fri, Feb 22, 2019 at 3:43 AM Magnus Hagander wrote:
> We are certainly not supposed to go DROP SCHEMA on the temp namespaces, ...
Actually, I think that's supposed to work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Magnus Hagander writes:
> The reason for the crash is 6d842be6c11, where Tom added an assert for
> passing null into %s. But I don't think we can blame that patch for the
> problem -- it's passing the NULL there in the first place that's the
> problem.
Indeed; this crash existed on some platforms
19 matches
Mail list logo
