From: | Alex Hunsaker <badalex(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DROP TABLE vs inheritance |
Date: | 2009-05-12 20:57:07 |
Message-ID: | 34d269d40905121357u73b615b1w2f1ce2ccddb8df5c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 12, 2009 at 14:40, Alex Hunsaker <badalex(at)gmail(dot)com> 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 immediately even if there are say a
> few hundred non-owner clients trying to lock it.
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?
(pre 100 clients)
=> LOCK table test_lock;
LOCK TABLE
Time: 1.955 ms
(now with 100 non-owner clients trying to do ALTER TABLE)
=> LOCK TABLE test_lock;
LOCK TABLE
Time: 71.746 ms
*shrugs*
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-05-12 21:10:24 | Re: [COMMITTERS] pgsql: Fix LOCK TABLE to eliminate the race condition that could make it |
Previous Message | Simon Riggs | 2009-05-12 20:50:38 | Re: [COMMITTERS] pgsql: Fix LOCK TABLE to eliminate the race condition that could make it |