AW: AW: AW: AW: relation ### modified while in use
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: AW: AW: AW: relation ### modified while in use |
Дата | |
Msg-id | 11C1E6749A55D411A9670001FA6879633680C5@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: AW: AW: AW: AW: relation ### modified while in use
|
Список | pgsql-hackers |
> > You were talking about the "select only" case (and no for update eighter). > > I think that select statements need a shared lock for the duration of their > > execution only. > > You seem to think that locks on individual tuples conflict with > table-wide locks. Yes, very much so. Any other way would be subject to the same quirks you would like to avoid, no ? > AFAIK that's not true. well, imho room for improvement. > The only way to prevent > another xact from gaining AccessExclusiveLock on a table is to be > holding some lock *on the table*. Yes, and holding a row exclusive lock must imho at least grab a shared table lock (to avoid several problems, like missing an index update, inserting a null into a newly added not null column ...). Alternately the table exclusive lock could honour row locks (probably not possible, since we don't track those do we ?). > As for your claim that read-only xacts don't need to worry about > preventing schema updates, what of adding/deleting ON SELECT rules? Well, depends on what that rule does, you mean a new rule ? Ad hoc I don't see a problem based on the idea that all modification gets appropriate locks. Andreas
В списке pgsql-hackers по дате отправления: