From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Fabrízio Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reduce lock levels others reloptions in ALTER TABLE |
Date: | 2016-03-01 19:00:36 |
Message-ID: | CA+TgmoZSn+=ewPE2yTuBYzCF-HZcScc=KL9dbs1Ueb3S7vBA8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 29, 2016 at 12:58 PM, Fabrízio de Royes Mello
<fabriziomello(at)gmail(dot)com> wrote:
> Some time ago we added [1] the infrastructure to allow different lock levels
> for relation options.
>
> So per discussion [2] the attached patch reduce lock levels down to
> ShareUpdateExclusiveLock for:
> - fastupdate
> - fillfactor
> - gin_pending_list_limit
> - seq_page_cost
> - random_page_cost
> - n_distinct
> - n_distinct_inherited
> - buffering
I am of the opinion that there needs to be comments or a README or
some kind of documentation somewhere indicating the rationale for the
lock levels we choose here. Just changing it without analyzing why a
certain level is sufficient for safety and no higher than necessary
seems poor. And the reasoning should be documented for future
readers.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-03-01 19:02:44 | Re: The plan for FDW-based sharding |
Previous Message | Petr Jelinek | 2016-03-01 18:56:58 | Re: The plan for FDW-based sharding |