Re: [HACKERS] [PATCH] Lockable views

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: nagata(at)sraoss(dot)co(dot)jp
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] [PATCH] Lockable views
Date: 2017-12-29 14:39:39
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>> >> > 1) Leave as it is (ignore tables appearing in a subquery)
>> >> >
>> >> > 2) Lock all tables including in a subquery
>> >> >
>> >> > 3) Check subquery in the view
>> >
>> >> > So it seem #1 is the most reasonable way to deal with the problem
>> >> > assuming that it's user's responsibility to take appropriate locks on
>> >> > the tables in the subquery.
>> >
>> > I adopted #1 and I didn't change anything about this.
>> Looks good to me except that the patch lacks documents and the
>> regression test needs more cases. For example, it needs a test for the
>> case #1 above: probably using pg_locks to make sure that the tables
>> appearing in the subquery do not hold locks.
> Attached is the update patch, v3. I add some regression test and
> the documentation.

The patch produces a warning.

/home/t-ishii/lock_view-v3.patch:542: trailing whitespace.
-- Verify that we can lock a auto-updatable views
warning: 1 line adds whitespace errors.

Your addition to the doc:
+ Automatically updatable views (see <xref linkend="sql-createview">)
+ that do not have <literal>INSTEAD OF</> triggers or <literal>INSTEAD</>
+ rules are also lockable. When a view is locked, its base relations are
+ also locked recursively with the same lock mode.

does not mention about the point:

>> >> > 1) Leave as it is (ignore tables appearing in a subquery)

Best regards,
Tatsuo Ishii
SRA OSS, Inc. Japan

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-12-29 14:45:09 Re: [HACKERS] Commits don't block for synchronous replication
Previous Message Marina Polyakova 2017-12-29 14:26:15 Re: [HACKERS] why not parallel seq scan for slow functions