Re: Problems with ALTER DOMAIN patch
От | Rod Taylor |
---|---|
Тема | Re: Problems with ALTER DOMAIN patch |
Дата | |
Msg-id | 1039579765.19960.12.camel@jester обсуждение исходный текст |
Ответ на | Re: Problems with ALTER DOMAIN patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Problems with ALTER DOMAIN patch
Re: Problems with ALTER DOMAIN patch |
Список | pgsql-hackers |
On Tue, 2002-12-10 at 22:56, Tom Lane wrote: > Rod Taylor <rbt@rbt.ca> writes: > >> 2. Insufficient locking, guise 2: there's no protection against someone > >> else adding a column or table while you're processing an ALTER DOMAIN, > >> either. This means that constraint checks will be missed. Example: > > > Locking the entry in pg_type doesn't prevent that? > > If there were such a thing as "locking the entry in pg_type", it might > prevent that, but (a) there isn't, and (b) your code wouldn't invoke it > if there were. Reading a row should surely not be tantamount to > invoking an exclusive lock on it. Hrm... Yes.. I came to that conclusion while walking home. My concepts of locking, and what actually happens in PostgreSQL are two completely different things. > In any case, other backends might have the pg_type entry in their > syscaches, in which case their references to the type would be quite > free of any actual read of the pg_type row that might fall foul of > your hypothetical lock. So... Basically I'm cooked. > relation's pg_class row. We have no such locks on types at present, > but I think it may be time to invent 'em. I'd be happy to use them once created. Thanks again for the help. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
В списке pgsql-hackers по дате отправления: