On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera <alvherre@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?
> (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?
