Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );
От | Michael Paquier |
---|---|
Тема | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |
Дата | |
Msg-id | CAB7nPqQ1gg-x9HR3TagJXktfUFhPZYP2=pJ6GCdj-AH=W_-c5A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Fri, Jul 31, 2015 at 11:28 AM, Andres Freund <andres@anarazel.de> wrote: > >> @@ -57,7 +57,8 @@ static relopt_bool boolRelOpts[] = > > If we go through this list, I'd rather make informed decisions about > each reloption. Otherwise we're going to get patches for each of them > separately over the next versions. Just dropping quickly a reply: I meant table relopts only, excluding the index stuff for now regarding the isolation tests. >> + AccessExclusiveLock >> + foreach(cell, defList) >> + { >> + DefElem *def = (DefElem *) lfirst(cell); >> + int i; >> + >> + for (i = 0; relOpts[i]; i++) >> + { >> + if (pg_strncasecmp(relOpts[i]->name, def->defname, relOpts[i]->namelen + 1) == 0) >> + { >> + if (lockmode < relOpts[i]->lockmode) >> + lockmode = relOpts[i]->lockmode; >> + } >> + } >> + } >> + >> + return lockmode; >> +} > > We usually don't compare lock values that way, i.e. there's not > guaranteed to be a strict monotonicity between lock levels. I don't > really agree with that policy, but it's nonetheless there. Yeah, there are some in lock.c but that's rather localized. -- Michael
В списке pgsql-hackers по дате отправления: