Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] remove redundant ownership checks

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>,Bruce Momjian <bruce(at)momjian(dot)us>,KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] remove redundant ownership checks
Date: 2010-01-13 21:28:16
Message-ID: 20100113212816.GJ17756@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* Alex Hunsaker (badalex(at)gmail(dot)com) wrote:
> On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
> > Im of the opinion if we are going to be meddling with the permission
> > checks [...]
> 
> Specifically:
> http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
> 
> Sounds like most solutions would put us back to exactly what you were
> trying to fix. :(  Maybe its a moot point.  But I figured while we are
> talking about ALTER permissions....

Maybe I missed it, but I don't see anything that said ALTER TABLE was
changed or fixed to address this concern.  It might make the timing
increase some, and it'd be interesting in any case to see just what the
timing change looked like, but I don't know that it's really all that
important..  At least if the timing didn't change much we could claim
that this didn't affect this use-case, but I don't believe it shouldn't
be done if it does.

I don't see a way to actually *fix* the problem of not allowing someone
who doesn't have all the right permissions to not lock the table at
all.  Taking a share lock and then trying to upgrade it isn't a good
idea either.

	Thanks,

		Stephen

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-13 21:29:42
Subject: Re: [PATCH] remove redundant ownership checks
Previous:From: Peter EisentrautDate: 2010-01-13 21:27:37
Subject: Re: plpython3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group