Re: pg_tablespace_size()

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dave Page <dpage(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_tablespace_size()
Date: 2007-10-12 17:14:45
Message-ID: 470FAB85.2070700@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Tom Lane wrote:
>>> * Just remove the above-quoted lines. Superusers should be allowed to
>>> shoot themselves in the foot. (I'm not actually sure that there would
>>> be any bad consequences from putting an ordinary table into pg_global
>>> anyway.
>
>> Is there ever *any* reason for doing this?
>
> Probably not a good one, and I suspect there would be some funny
> misbehaviors if you were to clone the database containing the table.
> The table would be physically shared but logically not.

yuck.

> What I'm inclined to do about it is is adopt my suggestion #2 (move the
> location of the defense), since "permission denied" for a superuser is
> a pretty unhelpful error message anyway.

Ok. Works for me.

>>> * Decide that we should allow anyone to do pg_tablespace_size('pg_global')
>>> and put in a special wart for that in dbsize.c. This wasn't part of
>>> the original agreement but maybe there's a case to be made for it.
>
>> That's pretty much the same thing, right?
>
> Well, no, I was suggesting that we might want to special-case pg_global
> as a tablespace that anyone (superuser or no) could get the size of.
> This is actually independent of whether we change the aclmask behavior.

Oh, ok, I see. Then my vote is for the other solution = not allowing
anybody to do this.

//Magnus

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-10-12 17:30:30 Re: First steps with 8.3 and autovacuum launcher
Previous Message Tom Lane 2007-10-12 17:13:24 Re: pg_tablespace_size()