<div dir="ltr"><div class="gmail_extra">On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera <<a
href="mailto:alvherre@2ndquadrant.com"target="_blank">alvherre@2ndquadrant.com</a>> wrote:<br />><br />>
Fabríziode Royes Mello wrote:<br />><br />> > Ok guys. The attached patch refactor the reloptions adding a new
field<br/>> > "lockmode" in "relopt_gen" struct and a new method to determine the<br />> > required lock
levelfrom an option list.<br />> ><br />> > We need determine the appropriate lock level for each
reloption:<br/>><br />> I don't think AccessShareLock is appropriate for any option change. You<br />> should
beusing a lock level that's self-conflicting, as a minimum<br />> requirement, to avoid two processes changing the
valueconcurrently. <br /><br /></div><div class="gmail_extra">What locklevel do you suggest? Maybe ShareLock?<br
/></div><divclass="gmail_extra"><br /><br />> (I would probably go as far as ensuring that the lock level specified
in<br/>> the table DoLockModesConflict() with itself in an Assert somewhere.)<br />><br /><br /></div><div
class="gmail_extra">IfI understood this is to check if the locklevel of the reloption list don't conflict one each
other,is it?<br /></div><div class="gmail_extra"><br /></div><div class="gmail_extra">Regards,<br /><br /></div><div
class="gmail_extra">--<br/>Fabrízio de Royes Mello<br />Consultoria/Coaching PostgreSQL<br />>> Timbira: <a
href="http://www.timbira.com.br"target="_blank">http://www.timbira.com.br</a><br />>> Blog: <a
href="http://fabriziomello.github.io"target="_blank">http://fabriziomello.github.io</a><br />>> Linkedin: <a
href="http://br.linkedin.com/in/fabriziomello"target="_blank">http://br.linkedin.com/in/fabriziomello</a><br />>>
Twitter:<a href="http://twitter.com/fabriziomello" target="_blank">http://twitter.com/fabriziomello</a><br />>>
Github:<a href="http://github.com/fabriziomello" target="_blank">http://github.com/fabriziomello</a></div></div>