From: | Rod Taylor <rbt(at)rbt(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Problems with ALTER DOMAIN patch |
Date: | 2002-12-11 04:09:26 |
Message-ID: | 1039579765.19960.12.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2002-12-10 at 22:56, Tom Lane wrote:
> Rod Taylor <rbt(at)rbt(dot)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(at)rbt(dot)ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-12-11 04:15:36 | Re: Problems with ALTER DOMAIN patch |
Previous Message | Bruce Momjian | 2002-12-11 04:08:28 | Re: PQnotifies() in 7.3 broken? |