Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

Поиск
Список
Период
Сортировка
От Fabrízio de Royes Mello
Тема Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );
Дата
Msg-id CAFcNs+pmeTvcXiXt3rHTbmtmNpSQWBW4AWxWa187_HN-GqgkhA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );  (Andres Freund <andres@anarazel.de>)
Ответы Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
<div dir="ltr"><br />On Thu, Jul 30, 2015 at 11:28 PM, Andres Freund <<a
href="mailto:andres@anarazel.de">andres@anarazel.de</a>>wrote:<br />><br />> > @@ -57,7 +57,8 @@ static
relopt_boolboolRelOpts[] =<br />><br />> If we go through this list, I'd rather make informed decisions about<br
/>>each reloption. Otherwise we're going to get patches for each of them<br />> separately over the next
versions.<br/>><br /><br />I have no problem to do this change now instead of wait for next versions...<br /><br
/><br/>> > @@ -73,7 +75,8 @@ static relopt_bool boolRelOpts[] =<br />> >               {<br />> >    
                 "fastupdate",<br />> >                       "Enables \"fast update\" feature for this GIN
index",<br/>> > -                     RELOPT_KIND_GIN<br />> > +                     RELOPT_KIND_GIN,<br
/>>> +                     AccessExclusiveLock<br />> >               },<br />> >              
true<br/>> >       },<br />><br />><br />> > @@ -95,7 +99,8 @@ static relopt_int intRelOpts[] =<br
/>>>               {<br />> >                       "fillfactor",<br />> >                      
"Packstable pages only to this percentage",<br />> > -                     RELOPT_KIND_HEAP<br />> > +    
               RELOPT_KIND_HEAP,<br />> > +                     AccessExclusiveLock<br />> >              
},<br/>> >               HEAP_DEFAULT_FILLFACTOR, HEAP_MIN_FILLFACTOR, 100<br />><br />> > [some other
fillfactorsettings]<br />><br />> >       {<br />> >               {<br />> >                    
 "gin_pending_list_limit",<br />> >                       "Maximum size of the pending list for this GIN index,
inkilobytes.",<br />> > -                     RELOPT_KIND_GIN<br />> > +                    
RELOPT_KIND_GIN,<br/>> > +                     AccessExclusiveLock<br />> >               },<br />> >
             -1, 64, MAX_KILOBYTES<br />> >       },<br />> > @@ -297,7 +325,8 @@ static relopt_string
stringRelOpts[]=<br />> >               {<br />> >                       "buffering",<br />> >      
               "Enables buffering build for this GiST index",<br />> > -                     RELOPT_KIND_GIST<br
/>>> +                     RELOPT_KIND_GIST,<br />> > +                     AccessExclusiveLock<br />>
>              },<br />> >               4,<br />> >               false,<br />><br />> Why? These
optionsjust change things for the future and don't influence<br />> past decisions. It seems unproblematic to change
them.<br/>><br /><br />+1<br /><br /><br />> > @@ -259,7 +283,8 @@ static relopt_real realRelOpts[] =<br
/>>>               {<br />> >                       "seq_page_cost",<br />> >                      
"Setsthe planner's estimate of the cost of a sequentially fetched disk page.",<br />> > -                    
RELOPT_KIND_TABLESPACE<br/>> > +                     RELOPT_KIND_TABLESPACE,<br />> > +                    
AccessExclusiveLock<br/>> >               },<br />> >               -1, 0.0, DBL_MAX<br />> >      
},<br/>> > @@ -267,7 +292,8 @@ static relopt_real realRelOpts[] =<br />> >               {<br />> >  
                   "random_page_cost",<br />> >                       "Sets the planner's estimate of the cost of
anonsequentially fetched disk page.",<br />> > -                     RELOPT_KIND_TABLESPACE<br />> > +    
               RELOPT_KIND_TABLESPACE,<br />> > +                     AccessExclusiveLock<br />> >        
     },<br />> >               -1, 0.0, DBL_MAX<br />> >       },<br />> > @@ -275,7 +301,8 @@ static
relopt_realrealRelOpts[] =<br />> >               {<br />> >                       "n_distinct",<br />>
>                      "Sets the planner's estimate of the number of distinct values appearing in a column
(excludingchild relations).",<br />> > -                     RELOPT_KIND_ATTRIBUTE<br />> > +              
     RELOPT_KIND_ATTRIBUTE,<br />> > +                     AccessExclusiveLock<br />> >               },<br
/>>>               0, -1.0, DBL_MAX<br />> >       },<br />> > @@ -283,7 +310,8 @@ static relopt_real
realRelOpts[]=<br />> >               {<br />> >                       "n_distinct_inherited",<br />>
>                      "Sets the planner's estimate of the number of distinct values appearing in a column
(includingchild relations).",<br />> > -                     RELOPT_KIND_ATTRIBUTE<br />> > +              
     RELOPT_KIND_ATTRIBUTE,<br />> > +                     AccessExclusiveLock<br />> >               },<br
/>>>               0, -1.0, DBL_MAX<br />> >       },<br />><br />> These probably are the settings
thatare most interesting to change<br />> without access exlusive locks.<br />><br /><br />+1<br /><br /><br
/>>>       j = 0;<br />> >       for (i = 0; boolRelOpts[i].<a href="http://gen.name">gen.name</a>; i++)<br
/>>> +     {<br />> > +             Assert(DoLockModesConflict(boolRelOpts[i].gen.lockmode,<br />> >
+                                                               boolRelOpts[i].gen.lockmode));<br />> >          
   j++;<br />> > +     }<br />> >       for (i = 0; intRelOpts[i].<a href="http://gen.name">gen.name</a>;
i++)<br/>> > +     {<br />> > +             Assert(DoLockModesConflict(intRelOpts[i].gen.lockmode,<br
/>>> +                                                                intRelOpts[i].gen.lockmode));<br />>
>              j++;<br />> > +     }<br />> >       for (i = 0; realRelOpts[i].<a
href="http://gen.name">gen.name</a>;i++)<br />> > +     {<br />> > +            
Assert(DoLockModesConflict(realRelOpts[i].gen.lockmode,<br/>> > +                                                
              realRelOpts[i].gen.lockmode));<br />> >               j++;<br />> > +     }<br />> >  
   for (i = 0; stringRelOpts[i].<a href="http://gen.name">gen.name</a>; i++)<br />> > +     {<br />> > +  
         Assert(DoLockModesConflict(stringRelOpts[i].gen.lockmode,<br />> > +                                    
                          stringRelOpts[i].gen.lockmode));<br />> >               j++;<br />> > +     }<br
/>>>       j += num_custom_options;<br />><br />> Doesn't really seem worth it to assert individually in
eachcase here to<br />> me.<br />><br /><br />What do you suggest then?<br /><br /><br /><br />> > +/*<br
/>>> + * Determine the required LOCKMODE from an option list<br />> > + */<br />> > +LOCKMODE<br
/>>> +GetRelOptionsLockLevel(List *defList)<br />> > +{<br />> > +     LOCKMODE    lockmode =
NoLock;<br/>> > +     ListCell    *cell;<br />> > +<br />> > +     if (defList == NIL)<br />> >
+            return AccessExclusiveLock;<br />> > +<br />> > +     if (need_initialization)<br />> >
+            initialize_reloptions();<br />> > +<br />> > +     foreach(cell, defList)<br />> > +    
{<br/>> > +             DefElem *def = (DefElem *) lfirst(cell);<br />> > +             int            
i;<br/>> > +<br />> > +             for (i = 0; relOpts[i]; i++)<br />> > +             {<br />>
>+                     if (pg_strncasecmp(relOpts[i]->name, def->defname, relOpts[i]->namelen + 1) == 0)<br
/>>> +                     {<br />> > +                             if (lockmode <
relOpts[i]->lockmode)<br/>> > +                                     lockmode = relOpts[i]->lockmode;<br
/>>> +                     }<br />> > +             }<br />> > +     }<br />> > +<br />>
>+     return lockmode;<br />> > +}<br />><br />> We usually don't compare lock values that way, i.e.
there'snot<br />> guaranteed to be a strict monotonicity between lock levels. I don't<br />> really agree with
thatpolicy, but it's nonetheless there.<br />><br /><br />And how is the better way to compare lock values to get
thehighest lock level? Perhaps creating a function to compare lock levels?<br /><br />Regards,<br /><br />*** This work
isfunded by Zenvia Mobile Results (<a href="http://www.zenvia.com.br">http://www.zenvia.com.br</a>)<br /><br />--<br
/>Fabríziode Royes Mello<br />Consultoria/Coaching PostgreSQL<br />>> Timbira: <a
href="http://www.timbira.com.br">http://www.timbira.com.br</a><br/>>> Blog: <a
href="http://fabriziomello.github.io">http://fabriziomello.github.io</a><br/>>> Linkedin: <a
href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/>>> Twitter: <a
href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a><br/>>> Github: <a
href="http://github.com/fabriziomello">http://github.com/fabriziomello</a></div>

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Adam Brightwell
Дата:
Сообщение: Re: security labels on databases are bad for dump & restore
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );