Re: [HACKERS] Reduce lock levels for reloptions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Reduce lock levels for reloptions
Дата
Msg-id CA+TgmoYbQ7gZ4XxuuyYaJJz5xTRR+m5M1b5GuzbWgV2hjjYq1w@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] Reduce lock levels for reloptions  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
On Sat, Feb 25, 2017 at 11:24 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Patch to reduce lock levels of various relation-level options,
> following on from earlier work by Fabrizio, with additional work and
> documentation by me.

I have reviewed this patch and I think it looks reasonable.  I think
that the behavior will be that overlapping transactions may or may not
pick up the new values depending on whether they already have a lock
on the relation and whether they happen to have a relcache flush for
some other reason, but new transactions started after the value is
altered via DDL should always see the new value, because they will
always do AcceptInvalidationMessages() after locking the relation, and
if they haven't yet picked up the value by that point, then they will
see it then.  If that sounds right, maybe we should document someplace
in the SGML documentation that new values of reloptions which can be
changed without AEL might or might not be seen by overlapping
transactions; perhaps the lock levels for each reloption should also
be documented (since, as evidenced by this and previous patches,
people obviously do care about what those levels are).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Allow pg_dumpall to work without pg_authid