Thread: Locking for Rename To new_name works differently for different objects
I have observed that for renaming some of the objects
ExecRenameStmt()
{
..
..
case OBJECT_AGGREGATE:
case OBJECT_COLLATION:
case OBJECT_CONVERSION:
case OBJECT_EVENT_TRIGGER:
case OBJECT_FDW:
...
address = get_object_address(stmt->renameType,
stmt->object, stmt->objarg,
&relation,
AccessExclusiveLock, false);
Assert(relation == NULL);
catalog = heap_open(address.classId, RowExclusiveLock);
AlterObjectRename_internal(catalog,
address.objectId,
stmt->newname);
..
}
AccessExclusiveLock is taken on object whereas for
other kind of objects no lock is taken on object before
renaming the object.
The object's that are renamed via AlterObjectRename_internal()
takes the lock (during get_object_address() call) whereas for
takes the lock (during get_object_address() call) whereas for
other objects, there is no lock. I think there is exception to it
i.e for Rename table, it also takes lock. Refer below function:
ExecRenameStmt()
{
..
..
case OBJECT_AGGREGATE:
case OBJECT_COLLATION:
case OBJECT_CONVERSION:
case OBJECT_EVENT_TRIGGER:
case OBJECT_FDW:
...
address = get_object_address(stmt->renameType,
stmt->object, stmt->objarg,
&relation,
AccessExclusiveLock, false);
Assert(relation == NULL);
catalog = heap_open(address.classId, RowExclusiveLock);
AlterObjectRename_internal(catalog,
address.objectId,
stmt->newname);
..
}
Is there a reason for different locking strategy?
Amit Kapila <amit.kapila16@gmail.com> writes:
> I have observed that for renaming some of the objects
> AccessExclusiveLock is taken on object whereas for
> other kind of objects no lock is taken on object before
> renaming the object.
The usual theory for DDL updates of all types (not just rename)
is that an explicit lock is only needed for objects whose catalog
representation comprises more than one row. Otherwise, the implicit
locking involved in updating that row is sufficient to serialize
different updates.
regards, tom lane
On Wed, Oct 15, 2014 at 10:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapila16@gmail.com> writes: >> I have observed that for renaming some of the objects >> AccessExclusiveLock is taken on object whereas for >> other kind of objects no lock is taken on object before >> renaming the object. > > The usual theory for DDL updates of all types (not just rename) > is that an explicit lock is only needed for objects whose catalog > representation comprises more than one row. Otherwise, the implicit > locking involved in updating that row is sufficient to serialize > different updates. That's an interesting point that I hadn't considered, but I'm willing to believe that at least some of the differences might also be haphazard. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Oct 15, 2014 at 9:34 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Oct 15, 2014 at 10:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Amit Kapila <amit.kapila16@gmail.com> writes:
> >> I have observed that for renaming some of the objects
> >> AccessExclusiveLock is taken on object whereas for
> >> other kind of objects no lock is taken on object before
> >> renaming the object.
> >
> > The usual theory for DDL updates of all types (not just rename)
> > is that an explicit lock is only needed for objects whose catalog
> > representation comprises more than one row. Otherwise, the implicit
> > locking involved in updating that row is sufficient to serialize
> > different updates.
I am not sure if this rule is followed for all DDL's, as an example, I
> On Wed, Oct 15, 2014 at 10:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Amit Kapila <amit.kapila16@gmail.com> writes:
> >> I have observed that for renaming some of the objects
> >> AccessExclusiveLock is taken on object whereas for
> >> other kind of objects no lock is taken on object before
> >> renaming the object.
> >
> > The usual theory for DDL updates of all types (not just rename)
> > is that an explicit lock is only needed for objects whose catalog
> > representation comprises more than one row. Otherwise, the implicit
> > locking involved in updating that row is sufficient to serialize
> > different updates.
I am not sure if this rule is followed for all DDL's, as an example, I
tried to compare for FUNCTION and SCHEMA.
Function has entries in pg_proc, pg_depend (schema, language,
returntype, etc.), so by above theory any update should take explicit
lock which I think holds good whereas if we see for Schema, it has
entries in pg_namespace, pg_depend (owner), but it doesn't take
explicit lock during Rename.
Yet another anomaly is for "Comment on <Object> .." there is only
Yet another anomaly is for "Comment on <Object> .." there is only
one row in pg_description, however it still takes explicit lock to
avoid concurrent activity which looks right to me.
> That's an interesting point that I hadn't considered, but I'm willing
> to believe that at least some of the differences might also be
> haphazard.
Yeah, I also think so, is it important enough that we spend energy to
> to believe that at least some of the differences might also be
> haphazard.
Yeah, I also think so, is it important enough that we spend energy to
find all such differences and fix them.