если изменение типа данных вызвало перезапись всей таблицы ?

Привет! Подскажите, pgdumpall умеет с 12 -> 13?

т.е. alter column создает новые файл\файлы, а при откате дропает их?

дамп снимается с конкретной версии
и не знает куда вы его будете заливать
может и прокатит )

но может вам нужен pg_upgrade ?

не могу ручаться, но думаю что как-то так и происходит
не каждый алтер конечно, но в вашем случае думаю происходит именно что-то такое

Хз. Переношу с сервака на новый, думаю поставить сразу 13

сейчас проверю

снимите basebackup и выполните pg_upgrade
имхо, самый правильный способ

Вы правы

select pg_table_size('t1'),pg_relation_size('t1'),(select oid||':'||relfilenode from pg_class where relname='t1');
pg_table_size | pg_relation_size |  ?column?  
---------------+------------------+-------------
       761856 |           753664 | 16438:16455
(1 row)

postgres=# select pg_table_size('t1'),pg_relation_size('t1'),(select oid||':'||relfilenode from pg_class where relname='t1');
pg_table_size | pg_relation_size |  ?column?  
---------------+------------------+-------------
        57344 |            57344 | 16438:16842
(1 row)

postgres=# rollback ;
ROLLBACK
postgres=# select pg_table_size('t1'),pg_relation_size('t1'),(select oid||':'||relfilenode from pg_class where relname='t1');
pg_table_size | pg_relation_size |  ?column?  
---------------+------------------+-------------
       761856 |           753664 | 16438:16455
(1 row)

postgres=# begin;
BEGIN
postgres=# alter table t1 alter COLUMN sss type bigint using substring(sss from 1 for 2)::bigint;ALTER TABLE
postgres=# select pg_table_size('t1'),pg_relation_size('t1'),(select oid||':'||relfilenode from pg_class where relname='t1');
pg_table_size | pg_relation_size |  ?column?  
---------------+------------------+-------------
        57344 |            57344 | 16438:16845
(1 row)

postgres=# commit;
COMMIT
postgres=# select pg_table_size('t1'),pg_relation_size('t1'),(select oid||':'||relfilenode from pg_class where relname='t1');
pg_table_size | pg_relation_size |  ?column?  
---------------+------------------+-------------
        57344 |            57344 | 16438:16845
(1 row)

спасибо!

да не за что )

Спасибо. Буду пробовать

pgdumpall v13 "умеет" все* предыдущие версии. Но восстанавливаться он обязан только на сервере v13.
* на самом деле, кажется, не все, но очень далеко в прошлое.

Наверное я лучше сделаю pg_dump)))

INSERT INTO tbl3 (username, password, email, ip)
SELECT name, pass, email, null FROM tbl1 из предложеного вариантов  инете нашел такое, есть еще?

Хмм... это то же самое, только работы больше, а ограничения точно те же (да и pgdumpall придётся использовать всё равно). ;)
Разве что опций / форматов больше. А вообще, pg_upgrade, скорее всего, будет проще / [намного] быстрее / надёжнее.

Всем привет, можно ли как-то вынести настройки для отдельных ролей в конфигурационный файл?
Например хочу установить для отдельного пользователя параметр idle_in_transaction_session_timeout в отличное от кластера значение. Где-то кроми pg_shadow  сохраниться это значение после alter user?  и можно ли как-то сделать этот процесс переносимым? могу ли я прописать в конфиге что-то типа user.idle_in_transaction_session_timeout = '1499'?

Добрый день, а проверку уникальности уникального индекса можно отключить?

создать не уникальный, удалить уникальный

Создаёт стороннее ПО, поведение поменять нельзя