Re: [HACKERS] Reduce lock levels for reloptions - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Reduce lock levels for reloptions
Date
Msg-id CA+TgmoYbQ7gZ4XxuuyYaJJz5xTRR+m5M1b5GuzbWgV2hjjYq1w@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Reduce lock levels for reloptions  (Simon Riggs <simon@2ndquadrant.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Allow pg_dumpall to work without pg_authid