надеюсь так понятнее

если файл с дампом базы создался но не хочет заливаться на чистый ПГ, значит дамп создан без команды create database

проблема в том что когда я пытаюсь через restore найти файл он его не видит

в этом случае базу на новом месте надо создать самому потом, подключившись к ней, запустить скрипт дампа

если файл с дампом базы создался но не хочет заливаться на чистый ПГ, значит дамп создан без команды create database

к сожалению до этого я не доходил

аа... файл с дампом потеряли

pgadmin новый/старый?

3 или 4?

хотя, без разницы.

блин

сори пжл

Сделайте еще раз выгрузку базы(дамп, экспорт)

вот же идиот, надо было All Files выбрать

и явно укажите путь до дампа, куда его положить

:)

я оказвается искал backup расширение

теперь всё получилось? :)

теперь всё получилось? :)

Спасибо щас смотрю

теперь всё получилось? :)

нет, выдал ошибку

я так понял это из за разности версий

Process Watcher - Restoring backup on the server 'PostgreSQL 9.6 (localhost:5432)'... X Restoring backup on the server 'PostgreSQL 9.6 (localhost:5432)'... Running command: C:\Program Files\PostgreSQL\9.6\bin\pg_restore.exe —host "localhost" —port "5432" —username "postgres" —no-password —dbname "isaProject" —no-owner —no-tablespaces —disable-triggers —create —clean —single-transaction —verbose "C:\\Users\\mrnar\\Desktop\\ISAPRO~2" Start time: Wed Apr 04 2018 17:10:15 GMT+0300 (RTZ 2 (зима) pg_restore: [���������] ������� ���� ������ ����� ��������� ������. ��������� ��� � ������� psql. Status:Failed (exit code: 1).Execution time:0.087 seconds DashboardPropertiesSQLStatisticsDependenciesDependents ><X Database sessions Transactions per second 0.00 0.000.200.400.600.801.00 Active Idle Total 0.0 0.01.02.03.04.0 Commits Rollbacks Transactions Tuples in Tuples out Block I/O 0.00 0.000.501.00 Inserts Updates Deletes 1000 02004006008001000 Fetched Returned 100 050100150200250300350 Reads Hits Database activity Sessions Locks Prepared Transactions PID User Application Client Backend start State Wait Event Blocking PIDs 3300 postgres pgAdmin 4 - DB:isaProject ::1 2018-04-04 17:08:37 MSK idle

эхх

давайте по порядку

для начала...

дамп может быть в разных форматах

рекомендую выгружать в виде текста

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

всё

не нужен вам ПГрестор пока

к сожалению сейчас доступа нету к ноуту((

тогда по F3 из total посмотрите, там текст читабельный?

если да, то проверьте наличие create database

оно вначале

эхх... кажется спугнул :)

Всем привет!

Слава!

Если нужен сквозной автоинкремент между партициями, какие есть варианты?

Если нужен сквозной автоинкремент между партициями, какие есть варианты?

А подробнее, что значит "сквозной автоинкремент"?

Если нужен сквозной автоинкремент между партициями, какие есть варианты?

Триггер'ы + sequence?

А подробнее, что значит "сквозной автоинкремент"?

Есть таблица, партицирована декларативно. Нужно в каждой таблице интовое поле, которое всегда будет увеличиваться

Триггер'ы + sequence?

Хотелось бы без триггеров

Есть таблица, партицирована декларативно. Нужно в каждой таблице интовое поле, которое всегда будет увеличиваться

Ну и в каждой по serial... хотя наверное, вы что-то не так объяснили.

postgres=# create table t1(id serial, txt text); CREATE TABLE postgres=# create table t2(id int, txt text); CREATE TABLE postgres=# postgres=# \d t1 Table "public.t1" Column | Type | Modifiers --------+---------+------------------------------------------------- id | integer | not null default nextval('t1_id_seq'::regclass) txt | text | postgres=# alter table t2 alter column id SET default nextval('t1_id_seq'::regclass); ALTER TABLE postgres=# insert into t1(txt) values ('t1-1'); INSERT 0 1 postgres=# insert into t1(txt) values ('t1-2'); INSERT 0 1 postgres=# insert into t2(txt) values ('t2-3'); INSERT 0 1 postgres=# insert into t2(txt) values ('t2-4'); INSERT 0 1 postgres=# insert into t1(txt) values ('t1-5'); INSERT 0 1 postgres=# insert into t2(txt) values ('t2-6'); INSERT 0 1 postgres=# select * from t1; id | txt ----+------ 1 | t1-1 2 | t1-2 5 | t1-5 (3 rows) postgres=# select * from t2; id | txt ----+------ 3 | t2-3 4 | t2-4 6 | t2-6 (3 rows) postgres=#

Подойдёт?

Подойдёт?

Создать один sequence и всем таблицам на него дефолт. Такое будет работать. Спасибо.

работать будет, но при этом вставки в партиции будет драться за один sequence. А в чём тогда был смысл партицирования? Более эффективным кажетсчя заавести на каждую партицию свой sequence с шагом равным числу партиций и уникальным оффсетом.

работать будет, но при этом вставки в партиции будет драться за один sequence. А в чём тогда был смысл партицирования? Более эффективным кажетсчя заавести на каждую партицию свой sequence с шагом равным числу партиций и уникальным оффсетом.

Что такое "драться"? Они же используют только кратковременные блокировки, разве нет? > А в чём тогда был смысл партицирования? А это уж вообще через край, Вам не кажется? ;)

А кэширования сиквенсов нет?

А кэширования сиквенсов нет?

Есть.

ну а за кратковременные блокировки что не может быть драки? >А это уж вообще через край, Вам не кажется? ;) Не понял. Что через край? Зачем-то ведь партиции то создавались? Вроде вполне логичный вопро - зачем? Очевидный ответ - для лучшей масштабируемости. Так вот у меня есть некторое опасение, что наличие шаред последовательности может эту масштабируемость убить.

Сколько занимает времени блокировка на возврат 1 значения из оперативной памяти?

ну а за кратковременные блокировки что не может быть драки? >А это уж вообще через край, Вам не кажется? ;) Не понял. Что через край? Зачем-то ведь партиции то создавались? Вроде вполне логичный вопро - зачем? Очевидный ответ - для лучшей масштабируемости. Так вот у меня есть некторое опасение, что наличие шаред последовательности может эту масштабируемость убить.

Зависит от профиля нагрузки.

эпопея с созданием индекса новый поворот в конкурентли режиме создался за 6 секунд без за 20 часов не создается локов при этом нет но если запускать из psql то он варнингует: WARNING: concurrent delete in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" если из navicat то просто висит на исполнении подскажите что это за фантомные транзакции, как их отловить, если их нет в pg_stat_activity из под рута?

ну а за кратковременные блокировки что не может быть драки? >А это уж вообще через край, Вам не кажется? ;) Не понял. Что через край? Зачем-то ведь партиции то создавались? Вроде вполне логичный вопро - зачем? Очевидный ответ - для лучшей масштабируемости. Так вот у меня есть некторое опасение, что наличие шаред последовательности может эту масштабируемость убить.

Хмм... следующий очевидный вопрос: Каким именно образом партиции связаны с лучшей масштабируемостью? А если "масштабируемость" убивается шаред последовательностью... что-то в PostgreSQL сильно не так с этими последовательностями, нет? ;)

Снова в одном треде оказались программисты с микросекундами и эксплуататоры с читаемым кодом

эпопея с созданием индекса новый поворот в конкурентли режиме создался за 6 секунд без за 20 часов не создается локов при этом нет но если запускать из psql то он варнингует: WARNING: concurrent delete in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" если из navicat то просто висит на исполнении подскажите что это за фантомные транзакции, как их отловить, если их нет в pg_stat_activity из под рута?

Не так тут что-то, с виду... Это точно _без_ CONCURRENTLY?

Снова в одном треде оказались программисты с микросекундами и эксплуататоры с читаемым кодом

Не-не. Просто не завезли пока в postgres partition global indexes

Коллеги, настраиваем notify бэкееда. Столкнулись с проблемой: выключеам бекенд, делаем апдейт в бд, включаем бек, notify не приходит (при вкл. бэке приходят). Как это решается?

А что вы хотите нотифицировать при мертвом бекенде?

Он на поднятии должен стейт восстановить сам

А что вы хотите нотифицировать при мертвом бекенде?

как сделать чтобы при поднятии бека . бек узнал что обновилось в бд?

Он при поднятии должен сбросить кеши

ERROR: S client not available

И вообще, не падать :)

Относительно чего он должен узнать обновления? Сколько копий бекенда смотрит в базу?

Относительно чего он должен узнать обновления? Сколько копий бекенда смотрит в базу?

один

А как база поймёт, что один? Почему так мало?

А как база поймёт, что один? Почему так мало?

учимся. используем java.

А относительно чего нужно получить обновление?

Вот было два бекенда

Отвалился первый, через пять минут второй, потом оба пришли - кто из них кто?

Не так тут что-то, с виду... Это точно _без_ CONCURRENTLY?

Точно без конкурентли будет часами... Хотя в пглок и пгстатактивити пусто

Других процессов нет

Фантомы какието

Дима писал что надо логи смотреть в пгбаунсере и постгресе

Хмм... да не должно там быть именно _пусто_. Какие запросы к pg_locks / pg_stat_activity вы используете для проверки?

Других процессов нет

А с точки зрения системы? ps что-то подозрительное говорит?

Привет, я от @bobrovskiy_roman, знаете такого?

Привет, я от @bobrovskiy_roman, знаете такого?

Уже да...

On 4 April 2018 at 22:00, Craig Ringer <craig@2ndquadrant.com> wrote: It's the error reporting issues around closing and reopening files with outstanding buffered I/O that's really going to hurt us here. I'll be expanding my test case to cover that shortly. Also, just to be clear, this is not in any way confined to xfs and/or lvm as I originally thought it might be. Nor is ext3/ext4's errors=remount-ro protective. data_err=abort doesn't help either (so what does it do?). What bewilders me is that running with data=journal doesn't seem to be safe either. WTF? [26438.846111] EXT4-fs (dm-0): mounted filesystem with journalled data mode. Opts: errors=remount-ro,data_err=abort,data=journal [26454.125319] EXT4-fs warning (device dm-0): ext4_end_bio:323: I/O error 10 writing to inode 12 (offset 0 size 0 starting block 59393) [26454.125326] Buffer I/O error on device dm-0, logical block 59393 [26454.125337] Buffer I/O error on device dm-0, logical block 59394 [26454.125343] Buffer I/O error on device dm-0, logical block 59395 [26454.125350] Buffer I/O error on device dm-0, logical block 59396 and splat, there goes your data anyway. It's possible that this is in some way related to using the device-mapper "error" target and a loopback device in testing. But I don't really see how.

эпопея продолжается

тут Dave Page наконец замержил мои патчи на докер образ pgadmin4, видимо можно ждать в новом релизе https://github.com/postgres/pgadmin4/commit/05e2e3cb397b21a669129feb067ac44d2fc916dd а пока есть превью в https://hub.docker.com/r/maksbotan/pgadmin4 главная фишка — образ легче примерно в два раза и третий питон вместо второго

Блин, чуваки, а вам не кажется, что 170 мешков для админ тулзовин - слишком дофига? И еще надо браузер иметь для того всего

по эпопее индексов версия ПГ PostgreSQL 9.5.12 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16), 64-bit словил очень похожий баг на этот: http://grokbase.com/p/postgresql/pgsql-hackers/12370r0hn7/warning-concurrent-insert-in-progress-within-table-resource

еще вот http://www.sql.ru/forum/1262609-1/oshibki-pri-vacuum-chto-delot

те же самые варнинги лезут

в поиске WARNING: concurrent insert in progress within table " много разных страниц выходит проблема видимо какая то в самом ПГ

аналайз выполнился на таблице без проблем, сейчас еще разз попробую создать индес без concurently

совсем простой тест, но индекс создался lsd=# create index blablabla on cstep using btree (id) where false; WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent delete in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent delete in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent delete in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep"

WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" CREATE INDEX lsd=# select * from pg_indexes where indexname = 'blablabla'; schemaname | tablename | indexname | tablespace | indexdef —----------+-----------+-----------+------------+---------------------------------------------------------------------— public | cstep | blablabla | | CREATE INDEX blablabla ON public.cstep USING btree (id) WHERE false (1 row)

по эпопее индексов версия ПГ PostgreSQL 9.5.12 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16), 64-bit словил очень похожий баг на этот: http://grokbase.com/p/postgresql/pgsql-hackers/12370r0hn7/warning-concurrent-insert-in-progress-within-table-resource

Почему вы вообще думаете, что это bug? Вы так и не показали запросов/результатов мониторинга, кстати...

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

откуда он берет WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep" WARNING: concurrent insert in progress within table "cstep"