> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> >> I am working on eliminating the "relation NNN modified 
> while in use"
> >> misfeature by instead grabbing a lock on each relation at first use
> >> in a statement, and holding that lock till end of transaction. 
> 
> > As anticipated, I object :-) 
> 
> Your objection is founded on two misunderstandings.  In the 
> first place, we are *always* inside a transaction when executing
> a query. It may be an implicit one-statement transaction, but it's
> still a transaction.
> In the second place, we already grab locks that we do not release till
> end of xact for all user-level queries.  The problem is that we grab
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Even for select?

> them too late, ie, in the executor.  I'm just planning to move up the
> grab till first use.

BTW, what about indices?

Vadim

Tue, 7 Nov 2000 09:54:14 -0800 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: AW: Issue NOTICE for attempt to raise lock level? 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> BTW, what about indices?

CREATE/DROP INDEX grab exclusive lock on the parent table, so there's no
problem with indexes as long as transactions that use the parent table
hold some kind of lock on that table.  I figure it's OK for the executor
to continue to grab and release locks on indexes on a per-scan basis.
It's just the parent table that we need a continuous lock on.

			regards, tom lane

Tue, 07 Nov 2000 14:41:09 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: Issue NOTICE for attempt to raise lock level? 
I said:
> CREATE/DROP INDEX grab exclusive lock on the parent table,

Correction: DROP INDEX grabs exclusive lock, CREATE only grabs a
ShareLock on the parent.  But that's OK since addition of an index
doesn't hurt existing readers.

			regards, tom lane

Tue, 07 Nov 2000 14:51:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: Issue NOTICE for attempt to raise lock level? 