Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

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.

>> It doesn't fix any of the non-relation object types.  That would be
>> nice to do, but I think it's material for a separate patch.
>
> I took a quick look under src/include/catalog and the objects that
> have namespace are
>
> - collation
> - constraint
> - conversion
> - extension
> - operator
> - operator class
> - operator family
> - function (proc)
> - ts_config
> - ts_dict
> - ts_parser
> - ts_template
> - (what's missing?)
>
> I agree with you that it's not worth doing everything, but function is
> nice to have. I don't mind if we don't have it with the other objects.

I think the fix for all of them will be very symmetrical; it's just
relations that have a different code path. I don't see the point of
plugging some but not others; that just provides a mixture of good and
bad examples for future hackers to copy, which doesn't seem ideal.

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