Skip to content

PostgreSQL: почему “GRANT ALL” все еще выдает ошибку “Must Be Owner” (должен быть владельцем)?

Posted by Sergey Moiseenko on

Пересказ статьи Prapti Patel. PostgreSQL: Why “GRANT ALL” Still Gives “Must Be Owner” Error


Проблема

Работая над проектом, связанным с PostgreSQL, я столкнулся со странной проблемой:

Я создал новую копию базы данных (xyz_copy) из существующей (xyz), кроме того, я создал новую роль с именем root. Я думал, что сделал все правильно, предоставляя root полный доступ:

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO root;

GRANT USAGE ON SCHEMA public TO root;

ALTER TABLE abc ADD COLUMN test_column TEXT;

ERROR:  must be owner of relation abc

Continue reading "PostgreSQL: почему “GRANT ALL” все еще выдает ошибку “Must Be Owner” (должен быть владельцем)?"

Краткие и тяжёлые блокировки PostgreSQL

Posted by mssqlhelp on

Автор: Николай Самохвалов #PostgresMarathon 2-001: Lightweight and heavyweight locks


Для разминки поговорим о легковесных (кратких) и тяжёлых блокировках (или «обычных блокировках», или просто «блокировках»).



Я опираюсь на следующие материалы:




Continue reading "Краткие и тяжёлые блокировки PostgreSQL"

Блокировки на уровне отношений

Posted by mssqlhelp on

Автор: Николай Самохвалов #PostgresMarathon 2-002: Relation-level locks


Поговорим о блокировках на уровне отношений и о разных путаницах, сюрпризах и о том, что важно помнить на практике.


Ключевая страница в документации Postgres, описывающая блокировки на уровне отношений, находится здесь: https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-TABLES


Эта страница в документации называется «13.3. Explicit Locking» («Явные блокировки») и может ввести в заблуждение, потому что на ней также говорится об неявных блокировках (например, если вы выполняете DML или DDL, блокировки накладываются неявно; а если вы выполняете LOCK или SELECT .. FOR UPDATE, вы явным образом запрашиваете блокировки). Впрочем, возможно, это просто моя терминологическая придирчивость.


На этой странице есть полезная «Table 13.2. Conflicting Lock Modes», которая помогает понять, как один запрос на получение блокировки может быть заблокирован другой, уже полученной или ожидающей (!) блокировкой:


Возможная путаница здесь связана со словом «row», встречающимся в названиях некоторых режимов блокировок, — не стоит думать, что эти режимы относятся к уровню строк. Это всё равно блокировки уровня отношений. Понятие блокировок уровня строк — особое, к нему мы ещё вернёмся отдельно. В документации эта путаница, впрочем, оговорена:




Помните, что все эти режимы — блокировки уровня таблицы, даже если в названии есть слово «row»; названия режимов сложились исторически.


Continue reading "Блокировки на уровне отношений"

Понимание рекурсивных запросов в PostgreSQL: пример иерархии процессов

Posted by Sergey Moiseenko on

Пересказ статьи Dmitry Romanoff. Understanding Recursive Queries in PostgreSQL: A Process Hierarchy Example


В мире баз данных иерархические данные зачатую могут вызывать сложности при обработке. Однако PostgreSQL предоставляет мощное средство для решения этой задачи: рекурсивные общие табличные выражения (CTE). В этой статье я объясню, как вы можете использовать рекурсивные CTE для работы с иерархическими данными, используя практический пример обслуживания процессов.

Задача: представление иерархических данных


Рассмотрим сценарий, в котором нам требуется представить иерархию процессов. Каждый процесс может иметь родительский процесс, формируя древообразную структуру. Наша цель - выполнить эффективный запрос к этим иерархическим данным и отобразить их в читабельном формате.
Continue reading "Понимание рекурсивных запросов в PostgreSQL: пример иерархии процессов"