|From:||Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>|
|Subject:||Re: [HACKERS] [PATCH] Lockable views|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> I didn't want to change the interface of view_query_is_auto_updatable()
> because this might be called from other third-patry software, so I renamed
> this function to view_query_is_auto_updatable_or_lockable() and added the flag
> to this. I created view_query_is_auto_updatable() as a wrapper of this function.
> I also made view_query_is_lockable() that returns a other message than
>> On Tue, 17 Oct 2017 11:59:05 +0900 (JST)
>> Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:
>> > 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.
SRA OSS, Inc. Japan
|Next Message||Michael Paquier||2017-12-28 00:47:52||Re: [HACKERS] taking stdbool.h into use|
|Previous Message||Tom Lane||2017-12-27 23:20:49||Re: Reproducible builds: genbki.pl and Gen_fmgrtab.pl|