Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); - Mailing list pgsql-hackers
| From | Fabrízio de Royes Mello |
|---|---|
| Subject | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |
| Date | |
| Msg-id | CAFcNs+pmeTvcXiXt3rHTbmtmNpSQWBW4AWxWa187_HN-GqgkhA@mail.gmail.com Whole thread Raw |
| In response to | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); (Andres Freund <andres@anarazel.de>) |
| Responses |
Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET (
.. );
|
| List | 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 by date: