Locking for Rename To new_name works differently for different objects
От | Amit Kapila |
---|---|
Тема | Locking for Rename To new_name works differently for different objects |
Дата | |
Msg-id | CAA4eK1+S22=PqJ0FxK-XdiA7UTPERsrfdompPDGkM4tKD=-FtA@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Locking for Rename To new_name works differently for different objects
|
Список | pgsql-hackers |
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?
В списке pgsql-hackers по дате отправления: