Re: Reduce lock levels for reloptions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reduce lock levels for reloptions
Date: 2017-02-26 08:23:46
Message-ID: CA+TgmoYbQ7gZ4XxuuyYaJJz5xTRR+m5M1b5GuzbWgV2hjjYq1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Sat, Feb 25, 2017 at 11:24 PM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-02-26 08:26:41 Re: Allow pg_dumpall to work without pg_authid
Previous Message Robert Haas 2017-02-26 08:17:07 Re: ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather)