Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts
Date
Msg-id 24715.949547413@sss.pgh.pa.us
Whole thread Raw
In response to RE: [HACKERS] SELECT FOR UPDATE leaks relation refcounts  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses Re: [HACKERS] SELECT FOR UPDATE leaks relation refcounts  (wieck@debis.com (Jan Wieck))
List pgsql-hackers
"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?)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Proposed Changes to PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL