Привет, ребят, подскажите кто с pg_restore фамильярен, как его заставить крупные таблицы восстанавливать в текстовый SQL файл? (база 62GB) пробую для небольшой таблицы, все гуд pg_restore --data-only --table=small_table database.csql > small_table.sql COPY small_table(field1, field2....) FROM stdin; <data> делаю тоже самое для огромной таблицы, получаю только pg_restore --data-only --table=big_table database.csql > big_table.sql COPY big_table(field1, field2....) FROM stdin; \.

postgres 9.2

а это не ограничение оси на размер файла..?

оси?

может фс всетаки?

не должно, Centos 6

ось у всех одна же, точно )

на раз дамп тут же лежит, значит не оно...

Привет сообщество. Есть вопрос про pathman. Попробовал добавить столбец к таблице потом посмотрел на тригеры и проверил апдейт. Тригер заточен на старые колонки и переносит только их, может что не так настроили?

Привет сообщество. Есть вопрос про pathman. Попробовал добавить столбец к таблице потом посмотрел на тригеры и проверил апдейт. Тригер заточен на старые колонки и переносит только их, может что не так настроили?

привет! могу посоветовать дропнуть старый тригер и пересоздать: select drop_triggers('abc'); select create_range_update_trigger('abc');

код создания update-триггеров не менялся кажется начиная с бета-версии. Думаю, его имеет смысл переписать. Добавим себе в туду

Спасибо, попробую=)

ок, тогда другой вопрос, как правильно восстановить только часть данных из кастомного бэкапа (-Fc) ? (для определенной таблицы для нужных значений поля с датой) я планировал вытащить нужную таблицу в текстовый sql, затем grep'нуть нужные мне даты и заинсертить в базу, раз с файликом не получается, возможно ли бэкап в новую базу с новым именем развернуть, не трогая старую? спрашиваю тк в бэкапе же лежит структура базы, в т/ч ее имя

-d <db name> -t <table name>

странно, # select count(*) from big_table; count ------- 0 (1 row)

Может этих данных нет в файле дампа? Какой у него размер?

дамп 62GB

для -l показывает что данные есть 29737; 0 21799 TABLE DATA public big_table user

а в новую базу без ключей типа только структура, или только данные разворачивали данную таблицу?

пробовал и целиком и только схему и только данные

схема восстанавливется

сейчас запущу восстановление всей базы в новую, может получится

а в big_table нет внешних ключей?

А констрейты разве не после восстановления данных?

я бы в этом случае сначала восстановил схему (--schema-only), затем дропнул констрейны, а потом восстановил данные (--data-only)

ну или можно не восстанавливать секцию post-data (--section)

да, CONSTRAINT используются!

62Гб дамп восстанавливать долго, имхо....

вот нашел --schema-only is equivalent to --section=pre-data --section=post-data. --data-only is equivalent >>>> to --section=data

ну вот надо —section=pre-data —section=data

т,е сначала сделать --section=pre-data для всей базы, а потом --section=data для нужной таблицы?

Post-data items consist of definitions of indexes, triggers, rules and constraints other than validated check constraints

можно сделать —section=pre-data для одной таблички. Убедиться что констрены для неё не создались или удалить их если создались. а потом для неё же —section=data

а чтобы даные восстанавливались быстрей, можно попробовать —jobs задать, сколь не жалко.

ок. тогда стопаю восстановление

а чтобы даные восстанавливались быстрей, можно попробовать —jobs задать, сколь не жалко.

ограничено только количеством таблиц. Если ресторить 1 таблицу не имеет смысла..

оно же вроде умеет крошить таблица на несколько воркеров?

вся база около 1000 таблиц

9.2?

да

ну есть оно там....

оно же вроде умеет крошить таблица на несколько воркеров?

нет

нет

я точно помню, что где то рассказывали что умеет. Там решь шла про 9.4 или 9.5. Сейчас не могу вспомнить где именно....

я точно помню, что где то рассказывали что умеет. Там решь шла про 9.4 или 9.5. Сейчас не могу вспомнить где именно....

я на 9.4 и на 9.5 не один раз ресторил БД в несколько потоков и вижу всегда что весь рестор тормозится на последней самой большой таблице, которая идёт в один поток. Возможный плюс нескольких потоков для одной таблицы есть когда идёт постороение индексов, вот это не проверял.

(0 rows)

\d big_table

восстановил сначала --section=pre-data

если кто-то конструирует промежуточные сущности без нужды, бейте его

Косяк есть с point <-> point

У нас гео точки, и сетка не квадратная получается

Правильно бдует работать только на экваторе )

ага, то есть, хочешь сказать, lseg() работал правильно? :)

retailnext_bak=# \d big_table Table "public.big_table" Column | Type | Modifiers -------------+----------+----------- field1 | bigint | not null field2 | date | not null field3 | smallint | not null field4 | smallint | field5 | integer | Check constraints: "dont_use_me" CHECK (1 < 0) NO INHERIT

констрейнов у оригинальной таблицы гораздо больше

point вообще не для географии

geography для географии

но это в следующих сериях

А точн

История успеха «Яндекс.Почты» с PostgreSQL https://habrahabr.ru/post/321756/

В ядре geography нету?

нет

ишь чего захотел, там и тангенса гиперболического-то нет

в общем запущу я фул рестор в 10 жобов

Херня этот ваш постгрес )

в новую базу

ну вот когда начинаешь писать математику для geography поверх point, вдруг такие вещи обнаруживаются :)

retailnext_bak=# \d big_table Table "public.big_table" Column | Type | Modifiers -------------+----------+----------- field1 | bigint | not null field2 | date | not null field3 | smallint | not null field4 | smallint | field5 | integer | Check constraints: "dont_use_me" CHECK (1 < 0) NO INHERIT

"dont_use_me" CHECK (1 < 0) NO INHERIT это же вечная ложь?

Херня этот ваш постгрес )

А не пошёл бы ты в Ораклу )

не спрашивайте меня, зачем это dont_use_me )

а попробуйте обычным инсертом что ни будь в эту таблицу вставить?

но восстанавливал схему через --section=pre-data

hmm ERROR: new row for relation "big_table" violates check constraint "dont_use_me"

ttt=# \d t Таблица "public.t" Столбец | Тип | Модификаторы —-------+---------+------------------------------------------------ id | integer | NOT NULL DEFAULT nextval('t_id_seq'::regclass) t | integer | Ограничения-проверки: "t_check" CHECK (1 < 0) NO INHERIT ttt=# insert into t ( DEFAULT VALUES SELECT TABLE VALUES ttt=# insert into t (t) values (10); ОШИБКА: новая строка в отношении "t" нарушает ограничение-проверку "t_check" ПОДРОБНОСТИ: Ошибочная строка содержит (1, 10).

удаляйте его....

там в констрейнах еще триггер был на функцию, возможно там обход для t_check лежит

но он не восстановился в --section=pre-data

возможно. У вас же задача табличку с дампа поднять? удалите этот констрейн и сделайте снова —section=pre-data для этой таблицы.

или вообще на боевой базе все эти констрейны выключены...

alter table big_table drop CONSTRAINT dont_use_me ;

что то мне подсказывает что при полном восстановлении эта табличка будет по прежнему пуста.

с такими то ограничениями :)

убрал, ручной инсерт работает, пробую восстановить опять --section=data

а как можно обойти 1 < 0 ?

через copy вероятно

хотя, это только предположение

или тупо отрубили, чтобы таблицу не меняли (хотя можно было выставить гранты)

(0 rows)

в общем запускаю фулл рестор в новую базу

copy обходит constraint?

в полном дампе точно есть данные для этой таблицы?

copy обходит constraint?

нет

уф

просто для «big_table» сильно быстро Вы получаете результат...

7 минут между сообщениями. За это время он какраз перечитывает весь дамп (62Гб) с диска и только. Больше ни чего не делает.

а результаты полного рестора мы узнаем скорей всего к завтрашнему дню :)

что ж за сервер-то?

А должна-ли сказываться авторизация (по паролю и без пароля) при подключении на производительности в ходе операций вставки (пачками по 1000)?

или тупо отрубили, чтобы таблицу не меняли (хотя можно было выставить гранты)

Какой хитрый хак, чтобы сделать таблицу read-only )

а кто ни будь может придумать зачем primary key делать varchar?

я просто пытаюсь воссоздать ход мысли тех архитекторов которые это давным давно сделали...