ну я полагаю, что это предлагалось сделать для того, чтобы заставить базу использовать другой существующий индекс

Не совсем, человек, который рассказывал доклад говорил, что ему в постгресе не хватает невидимых индексов, которые есть в оракле. И как аналог он предложил использовать такой механизм.

А если нет резервной копии, то можно как-то восстановить базу данных Postgresql?

Помолиться?

Конечно. Заново залить всё что там было))
А вот если БД просто повреждена, то есть варианты

Ок

Как вариант глянуть может не средствами бд бэкап делали... А того же гипервизора

На 9.6 делал апдейт pg_catalog.pg_index.indisvalid как раз чтобы сделать индекс инвалидным и построить план без использования этого индекса. На более новых версиях не проверял. Плюс, на проде я бы такое не стал использовать.

после того, как вы сделали такой апдейт, индекс не получает изменения от DML и становится действительно инвалидным, т.е. его надо перестраивать.

Так после построения плана, я rollback выполнял. Или она не транзакционна?

синхронизация состояния сессий в плане видения системного каталога — сложная штука. когда вы руками лезете в каталог с апдейтами с большой долей вероятности можно сказать, что какая-то сессия может не увидеть, или увидеть не так.
как минимум надо брать блокировку на таблицу, чтобы запретить параллельные DML-ы ( LOCK TABLE IN SHARE MODE; )

Всем привет

Я получаю все даты в GMT + 3, но часовой пояс сервера и часовой пояс postgresql-a и часовой пояс PHP (+ проекта) установлены как «Asia/Tashkent» (GMT + 5)

Что я могу сделать, чтобы все дата и время сохранились в GMT + 5?

P.S Сервер находиться в Москве

Дата и время в форме timestamptz хранятся одинаково, а все эти +6:45 по факту просто варианты отображения в пользовательской сессии.
Лично я эти преобразования в голове делаю со скрипом и подсматриваю в документацию.
Смотреть надо ( по памяти, не точно! )
select my_time at timezone;
set session timezone ...

В бд вроде правильно хранить в utc0

Понял, спасибо за ответы 👍

Есть крошечная таблица на 2 строки, куда иногда записывается ключи для шифрования.

CREATE TABLE "encrypt" (
    "name" text NOT NULL,
    "value" text
);

INSERT INTO "encrypt" ("name", "value") VALUES
('key1',  NULL),
('key2',  NULL);

Ключи используются для некоторых операций, по их окончании которых указанный ключ требуется удалить. Как я понимаю, простой UPDATE encrypt SET value = NULL WHERE name = "key1" просто создаст копию строки с пустым полем, а старая строка останется на диске на какое-то время. Что лучше будет в данном случае использовать, VACUUM encrypt или VACUUM FULL encrypt? В документации сказано что в первом случае просто высвобождается пространство для повторного использования (непонятно как именно). Во втором случае таблица переписывается в новый файл, и место отдаётся системе. Получается, старый файл физически на диске будет присутствовать?

CREATE TABLE "encrypt" (
    "name" text NOT NULL,
    "value" text
);

INSERT INTO "encrypt" ("name", "value") VALUES
('key1',  NULL),
('key2',  NULL);

так как там 2 строки, скорей всего и переписывания никакого не будет. и так все умещается

Старый файл будет удалён. А сколько его блоки будут валяться на диске - это вопрос к ФС.

В PgPro есть специальная "защищённая" версия, которая явно зачищает все освобождаемые данные в памяти и на диске.
Ноя не очень понимаю, почему вас так беспокоит сохранность старых ключей шифрования, а не новых...