Re: [HACKERS] [PATCH] Lockable views - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] [PATCH] Lockable views
Date
Msg-id 20180330002636.fdomghnrsdcauuat@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Lockable views  (Yugo Nagata <nagata@sraoss.co.jp>)
Responses Re: [HACKERS] [PATCH] Lockable views  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Re: [HACKERS] [PATCH] Lockable views  (Yugo Nagata <nagata@sraoss.co.jp>)
List pgsql-hackers
Hi,

On 2018-03-28 20:26:48 +0900, Yugo Nagata wrote:
> diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
> index b2c7203..96d477c 100644
> --- a/doc/src/sgml/ref/lock.sgml
> +++ b/doc/src/sgml/ref/lock.sgml
> @@ -46,6 +46,11 @@ LOCK [ TABLE ] [ ONLY ] <replaceable class="parameter">name</replaceable> [ * ]
>    </para>
>  
>    <para>
> +   When a view is specified to be locked, all relations appearing in the view
> +   definition query are also locked recursively with the same lock mode. 
> +  </para>

Trailing space added. I'd remove "specified to be" from the sentence.

I think mentioning how this interacts with permissions would be a good
idea too. Given how operations use the view's owner to recurse, that's
not obvious. Should also explain what permissions are required to do the
operation on the view.


> @@ -86,15 +92,17 @@ RangeVarCallbackForLockTable(const RangeVar *rv, Oid relid, Oid oldrelid,
>          return;                    /* woops, concurrently dropped; no permissions
>                                   * check */
>  
> -    /* Currently, we only allow plain tables to be locked */
> -    if (relkind != RELKIND_RELATION && relkind != RELKIND_PARTITIONED_TABLE)
> +

This newline looks spurious to me.


>  /*
> + * Apply LOCK TABLE recursively over a view
> + *
> + * All tables and views appearing in the view definition query are locked
> + * recursively with the same lock mode.
> + */
> +
> +typedef struct
> +{
> +    Oid root_reloid;
> +    LOCKMODE lockmode;
> +    bool nowait;
> +    Oid viewowner;
> +    Oid viewoid;
> +} LockViewRecurse_context;

Probably wouldn't hurt to pgindent the larger changes in the patch.


> +static bool
> +LockViewRecurse_walker(Node *node, LockViewRecurse_context *context)
> +{
> +    if (node == NULL)
> +        return false;
> +
> +    if (IsA(node, Query))
> +    {
> +        Query        *query = (Query *) node;
> +        ListCell    *rtable;
> +
> +        foreach(rtable, query->rtable)
> +        {
> +            RangeTblEntry    *rte = lfirst(rtable);
> +            AclResult         aclresult;
> +
> +            Oid relid = rte->relid;
> +            char relkind = rte->relkind;
> +            char *relname = get_rel_name(relid);
> +
> +            /* The OLD and NEW placeholder entries in the view's rtable are skipped. */
> +            if (relid == context->viewoid &&
> +                (!strcmp(rte->eref->aliasname, "old") || !strcmp(rte->eref->aliasname, "new")))
> +                continue;
> +
> +            /* Currently, we only allow plain tables or views to be locked. */
> +            if (relkind != RELKIND_RELATION && relkind != RELKIND_PARTITIONED_TABLE &&
> +                relkind != RELKIND_VIEW)
> +                continue;
> +
> +            /* Check infinite recursion in the view definition. */
> +            if (relid == context->root_reloid)
> +                ereport(ERROR,
> +                        (errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
> +                        errmsg("infinite recursion detected in rules for relation \"%s\"",
> +                                get_rel_name(context->root_reloid))));

Hm, how can that happen? And if it can happen, why can it only happen
with the root relation?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Incorrect use of "an" and "a" in code comments and docs
Next
From: Michael Paquier
Date:
Subject: Re: Enhance pg_stat_wal_receiver view to display connected host