Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

On Sun, Jan 15, 2012 at 11:03 AM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
> On Sat, Jan 14, 2012 at 6:48 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sat, Jan 14, 2012 at 5:25 AM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
>>> The patch looks ok, though I wonder if we could have a way to release
>>> the lock on namespace much before the end of transaction.
>>
>> Well, that wold kind of miss the point, wouldn't it?  I mean, the race
>> is that the process dropping the schema might not see the newly
>> created object.  The only way to prevent that is to hold some sort of
>> lock until the newly created object is visible, which doesn't happen
>> until commit.
>>
>>> I know it's a limited situation, though. Maybe the right way would be
>>> to check the namespace at the end of the transaction if any object is
>>> created, rather than locking it.
>>
>> And then what?  If you find that you created an object in a namespace
>> that's been subsequently dropped, what do you do about that?  As far
>> as I can see, your own really choice would be to roll back the
>> transaction that uncovers this problem, which is likely to produce
>> more rollbacks than just letting the deadlock detector sort it out.
>
> Right. I thought this patch introduced lock on schema in SELECT, but
> actually we'd been locking schema with SELECT since before the patch.

No, we lock the table with SELECT, not the schema. This doesn't add
any additional locking for DML: nor is any needed, AFAICS.

> So the behavior becomes consistent (between SELECT and CREATE) now
> with it. And I agree that my insist is pointless after looking more.

OK. Thanks for your review.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company