On Tue, Apr 7, 2015 at 10:15 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Fabrízio de Royes Mello wrote: > > On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera < alvhe...@2ndquadrant.com> > > wrote: > > > > > > Fabrízio de Royes Mello wrote: > > > > > > > Ok guys. The attached patch refactor the reloptions adding a new field > > > > "lockmode" in "relopt_gen" struct and a new method to determine the > > > > required lock level from an option list. > > > > > > > > We need determine the appropriate lock level for each reloption: > > > > > > I don't think AccessShareLock is appropriate for any option change. You > > > should be using a lock level that's self-conflicting, as a minimum > > > requirement, to avoid two processes changing the value concurrently. > > > > What locklevel do you suggest? Maybe ShareLock? > > ShareUpdateExclusive probably. ShareLock doesn't conflict with itself. >
Ok. > > > (I would probably go as far as ensuring that the lock level specified in > > > the table DoLockModesConflict() with itself in an Assert somewhere.) > > > > If I understood this is to check if the locklevel of the reloption list > > don't conflict one each other, is it? > > I mean > Assert(DoLockModesConflict(relopt_gen->locklevel, relopt_gen->locklevel)); > Understood... IMHO the better place to perform this assert is in "initialize_reloptions". Thoughts? -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog: http://fabriziomello.github.io >> Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello >> Github: http://github.com/fabriziomello
