RE: [HACKERS] SELECT FOR UPDATE leaks relation refcounts

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Thursday, February 03, 2000 10:00 AM
> 
> This seems to solve Oliver's problem, and the regress tests still pass,
> so I committed it a little while ago.
> 
> > Is there anything wrong with inserting heap_close(relation, NoLock)
> > immediately before 'continue;' ?
> 
> We can do that if it turns out my analysis is wrong and RowShareLock
> should indeed be grabbed on views as well as their underlying tables.
>

I couldn't judge whether the following current behavior has some meaning
or not.

Let v be a view;

Session-1
begin;
lock table v in exclusive mode;     (I don't know what this means)

Session-2
begin;
select * from v for update;
(blocked by Session-1)

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp