On Sun, Jan 15, 2012 at 11:03 AM, Hitoshi Harada <umi.tan...@gmail.com> wrote: > On Sat, Jan 14, 2012 at 6:48 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Sat, Jan 14, 2012 at 5:25 AM, Hitoshi Harada <umi.tan...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
