Re: [HACKERS] DROP TABLE vs inheritance

2009-05-13 Thread Tom Lane
Alex Hunsaker writes: > FWIW i just tested this with ~100 clients doing begin; ALTER TABLE > test_lock ADD COLUMN commit; here is the timing. Is there some other > concern that im not seeing? The situation where someone quickly acquires the lock isn't much of an issue, because they'll drop it a

Re: [HACKERS] DROP TABLE vs inheritance

2009-05-13 Thread Alex Hunsaker
On Tue, May 12, 2009 at 14:40, Alex Hunsaker wrote: > Hrm on second thought I think your right.  They only get the lock > until the permission check, and I have a hard time seeing how someone > can take real advantage of that.  The owner that is trying to lock > table should get the lock almost im

Re: [HACKERS] DROP TABLE vs inheritance

2009-05-13 Thread Alex Hunsaker
On Mon, May 11, 2009 at 21:18, Tom Lane wrote: > However, he can do that anyway via ALTER TABLE, which > will happily take out AccessExclusiveLock before it checks any > permissions.  So I'm not seeing the point of risking unsafe behavior > in LOCK TABLE. I would rather fix ALTER TABLE to do som

Re: [HACKERS] DROP TABLE vs inheritance

2009-05-12 Thread Alex Hunsaker
On Tue, May 12, 2009 at 12:10, Alex Hunsaker wrote: > On Mon, May 11, 2009 at 21:18, Tom Lane wrote: > >> However, he can do that anyway via ALTER TABLE, which >> will happily take out AccessExclusiveLock before it checks any >> permissions.  So I'm not seeing the point of risking unsafe behavior

Re: [HACKERS] DROP TABLE vs inheritance

2009-05-12 Thread Robert Haas
On Mon, May 11, 2009 at 11:18 PM, Tom Lane wrote: > So I'm not seeing the point of risking unsafe behavior > in LOCK TABLE. Me neither. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] DROP TABLE vs inheritance

2009-05-11 Thread Tom Lane
I wrote: > it seems that there is a reasonably simple solution: we could make > find_inheritance_children() and find_all_inheritors() acquire lock > on each child table as they scan pg_inherits, and do try_relation_open() > or equivalent to see if the child still exists. If not, assume the > table

[HACKERS] DROP TABLE vs inheritance

2009-05-11 Thread Tom Lane
There was just another complaint about something we've heard about before, namely that dropping a child table doesn't interact nicely with queries concurrently accessing the parent table: http://archives.postgresql.org/pgsql-bugs/2009-05/msg00113.php As I responded there, this isn't fixable by the