Нет. На "физической" реплике вообще ничего нельзя создать.

Имеете ввиду, что это не nullable тип?

На значения типа SERIAL накладывается ограничение — они не могут быть NULL.

Понял, спасибо. Что тогда можно использовать для Id'шников? Bigint?

Установите int8 и в триггер логику например вынесите.

спасибо

Да Bigint - это int8.

Вообще вот по типам:
https://postgrespro.ru/docs/postgresql/9.6/datatype-numeric

Большое спасибо, будем раскуривать

Приветствую! Простые скрипты управления БД работать будут. В pg_database_activity.sh и pg_database_information.sh, при показе прогресса операций, есть условия на версию PostgreSQL (c 9.6 и выше). А так проще попробовать, там одни выборки данных, но не все системные столбцы есть в старых версиях PostgreSQL.

'ALTER TABLE accounts ALTER COLUMN working_time TYPE bigint USING(trim(working_time)::bigint)'

Как можно поставить еще SET DEFAULT 0 ?

Понял, спасибо. Меня в первую очередь как раз скрипты собирающие информацию интересуют, для первичного анализа коллегам будет полезно. Попробуем)

Пользуйтесь на здоровье :)

Чтобы не писать вот так)

ALTER TABLE accounts ALTER COLUMN working_time DROP DEFAULT
ALTER TABLE accounts ALTER COLUMN working_time TYPE bigint USING(trim(working_time)::bigint)
ALTER TABLE accounts ALTER COLUMN working_time SET DEFAULT 0

приветствую. не могу разгадать загадку, буду благодарен за помощь
итак, есть два запроса к одной и той же таблице, оба запроса делают select ... order by id asc for update. в результате одновременного выполнения запросов получаю дэдлок.
отличаются эти запросы условием. в одном where id in (...), во втором where user_id in (...)
explain выдает на первый запрос вот что

QUERY PLAN
LockRows  (cost=0.42..25.35 rows=3 width=26) (actual time=4.446..5.036 rows=3 loops=1)
  ->  Index Scan using availability_availabilityqueue_pkey on availability_availabilityqueue  (cost=0.42..25.32 rows=3 width=26) (actual time=4.401..4.974 rows=3 loops=1)
        Index Cond: (id = ANY ('{fffff3e0-0c09-40cb-9cc0-29d79f557fa4,ffffb9f7-d2f9-4695-b448-dfee8b904bd7,ffffb151-a171-4803-a08d-fe618c9f9b26}'::uuid[]))
Planning Time: 0.128 ms
Execution Time: 5.057 ms

кусок эксплейна второго запроса

QUERY PLAN
LockRows  (cost=5638.39..5666.69 rows=2264 width=26) (actual time=5.034..5.036 rows=0 loops=1)
  ->  Sort  (cost=5638.39..5644.05 rows=2264 width=26) (actual time=5.033..5.035 rows=0 loops=1)
        Sort Key: id
        Sort Method: quicksort  Memory: 25kB
...

в обычной ситуации причиной дедлока является отсутствие сортировки (ну или различные сортировки). тут же сортировка указана. но у одного из запросов отсутствует в explain. это несколько смущает...

Коллеги, вспомнил о том, что вроде бы надо было запускать переиндексацию после апгрейда с 11 на 12 версии читаю документацию:
In new btree indexes, the maximum index entry length is reduced by eight bytes, to improve handling of duplicate entries (Peter Geoghegan)
This means that a REINDEX operation on an index pg_upgrade'd from a previous release could potentially fail.
Вроде бы не противоречит.
Читаю про pg_upgrade
All failure, rebuild, and reindex cases will be reported by pg_upgrade if they affect your installation; post-upgrade scripts to rebuild tables and indexes will be generated automatically.
Но после обновления не вижу скриптов по пересозданию индексов, да и не видел никогда, сбор статистики - да, удаление старых данных - тоже, но про пересоздание ничего нет.
Получается, что после апгрейда хорошо бы прогнать reindex system concurrently?

шалом ребят, а чем нынче модно экспортить метрики постгреса? пгвотч или что-то интересней есть?

Имеется в виду, что они будут сгенерированы, если необходимы для корректного upgrade, насколько я помню.
Т.е. обычно это не нужно.

У меня были остаточные воспоминания о том, что в 12 и в 13 версии индексы стали какие-то более поджарые и вроде бы как где-то слышал, что чтобы эти новые алгоритмы начали действовать индексы надо пересоздать...