Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts

> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > I couldn't judge whether the following current behavior has some meaning
> > or not.
>
> > Let v be a view;
>
> > lock table v in exclusive mode;     (I don't know what this means)
>
> Good question ... but it seems to me that it has to mean grabbing
> exclusive lock on the table(s) referred to by v.  Otherwise, if
> client A locks the view and client B locks the underlying table
> directly, they'll both pass the lock and be able to access/modify
> the underlying table at the same time.  That can't be right.
>
> The rewriter correctly passes SELECT FOR UPDATE locking from the
> view to the referenced tables, but I'm not sure whether it is
> bright enough to do the same for LOCK statements.  (Jan?)
   Isn't  LOCK  TABLE  a  utility  statement?  So  it doesn't go   through the rewriter.
   The LOCK code would have to do the  correct  locking  of  the   underlying  tables.  And  not  to  forget  cascaded
viewsor   possible subselects.
 
   Actually LockTableCommand() in command.c doesn't  do  it.  It   simply locks the view relation, what's definitely
wrong.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #