Re: Why release index relation lock

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: DT <kurt023(at)hotmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Why release index relation lock
Date: 2013-11-02 14:42:30
Message-ID: 9042.1383403350@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

DT <kurt023(at)hotmail(dot)com> writes:
> 1. What's the rule of index relation locking?
> 2. Releasing lock is for higher concurrency, but for INSERT/UPDATE, i did not find
> any operation that could get benefit from releasing index relation lock? Or to
> say : what will happen if we treat index relation lock like heap relation lock?

The reason we hold relation locks till end of transaction is mainly to
avoid transactional behavior surprises, eg an in-progress transaction
finding that a relation's schema has changed underneath it. There is
no corresponding risk for indexes, because there is no such thing as
a schema-definition change for an index --- short of dropping it,
which we disallow without having AccessExclusiveLock on the parent rel.
However, there are *physical* changes to indexes, such as REINDEX or
ALTER INDEX TABLESPACE, which require locking out other accesses till
they finish. So the point of locking indexes in use by a query is
just to interlock against those types of operations, and there's no
need to continue holding the lock once the query is done.

VACUUM might look like an exception, but it's not since it can't
run inside a transaction block. There's no meaningful difference
between statement end and transaction end for it.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Rowan Collins 2013-11-02 15:11:28 Re: changing port numbers so pgbouncer can read geoserver and postgres
Previous Message Adrian Klaver 2013-11-02 14:07:23 Re: Table with Field Serial - Problem