Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

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.
So the behavior becomes consistent (between SELECT and CREATE) now
with it. And I agree that my insist is pointless after looking more.

Thanks,
--
Hitoshi Harada