@vkuptcov будет жить. Поприветствуем!

@yanchumak будет жить. Поприветствуем!

Привет, подскажите пожалуйста, как делать синхронизацию таблицы Oracle в postgresql

Можете SymmetricDS посмотреть (сам не пользовался).

привет всем LOG: could not receive data from client: Connection reset by peer я так понял проблема в каком-то клиенте который не может подключиться, для этого нужно включить log_connection в postgresql.conf, как его применить без рестарта базы?

su - postgres -c "psql -c 'select pg_reload_conf();'"

из под рута если ;)

привет всем LOG: could not receive data from client: Connection reset by peer я так понял проблема в каком-то клиенте который не может подключиться, для этого нужно включить log_connection в postgresql.conf, как его применить без рестарта базы?

А когда именно происходит ошибка? В смысле, посреди connection, или при подключении? > для этого нужно включить log_connection в postgresql.conf, log_connections можно включить без restart-а, достаточно сделать reload любым из обычных способов (например, "pg_ctl reload", или "SELECT pg_reload_conf();", ну или просто послать postgres-у SIGHUP).

А когда именно происходит ошибка? В смысле, посреди connection, или при подключении? > для этого нужно включить log_connection в postgresql.conf, log_connections можно включить без restart-а, достаточно сделать reload любым из обычных способов (например, "pg_ctl reload", или "SELECT pg_reload_conf();", ну или просто послать postgres-у SIGHUP).

pg_ctl reload у меня что то не подхватывал перенастройку логов, селектом удачно.

pg_ctl reload у меня что то не подхватывал перенастройку логов, селектом удачно.

А ведь должен. Вы уверены, что он вообще срабатывал?

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

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

Всё равно это странно, т.к.: "pg_reload_conf sends a SIGHUP signal to the server, causing configuration files to be reloaded by all server processes." И в исходниках pg_reload_conf это всего лишь: pg_reload_conf(PG_FUNCTION_ARGS) { if (kill(PostmasterPid, SIGHUP)) <обработка ошибки kill> }

Мне нужно было файл лога пересоздать, после релоад он почему то не пересоздавался, видимо думал что еще пишет в тот же.

su - postgres -c "psql -c 'select pg_reload_conf();'"

Спасибо

А когда именно происходит ошибка? В смысле, посреди connection, или при подключении? > для этого нужно включить log_connection в postgresql.conf, log_connections можно включить без restart-а, достаточно сделать reload любым из обычных способов (например, "pg_ctl reload", или "SELECT pg_reload_conf();", ну или просто послать postgres-у SIGHUP).

Спасибо большое) ошибку пока отследить не удалось, кроме логов, поэтому и хотел спросить как безопаснос включить логи подключений. Скорее всего какой нибудь контейнер не съел пароль от базы

Мне нужно было файл лога пересоздать, после релоад он почему то не пересоздавался, видимо думал что еще пишет в тот же.

Файл лога? Так reload тут вообще ни при чём, если я правильно помню...

Тем не менее пересоздался, менял настройки логирования.

Тем не менее пересоздался, менял настройки логирования.

Вы документацию и исходники, которые я цитировал, видели? ;) Т.е., если у Вас "pg_ctl reload" и pg_reload_conf работают не одинаково, то либо не получилось послать сигнал postmaster-у (permissions?), либо Вы сделали "pg_ctl reload" не тому кластеру, например.

Привет! вопросик следующий надо сделать табличку и у строк должен быть родитель, и вложенность может быть любая, первое что пришло в голову это таблица с колонкой родителя, если родитель наивысший - нул, если нет - указываем в колонке айди строки и искать по таблице рекурсивно. Есть ли какие еще идеи по реализации. Спасибо!

Привет! вопросик следующий надо сделать табличку и у строк должен быть родитель, и вложенность может быть любая, первое что пришло в голову это таблица с колонкой родителя, если родитель наивысший - нул, если нет - указываем в колонке айди строки и искать по таблице рекурсивно. Есть ли какие еще идеи по реализации. Спасибо!

Это самый распостранённый и проверенный способ.

id-parentId типичный вариант, который часто применяется для таких задач. Стоит еще рассмотреть Nested sets и его вариации с прекалькулироваными значениями. В качестве отправной точки https://en.wikipedia.org/wiki/Nested_set_model

Это самый распостранённый и проверенный способ.

Спасибо огромное

id-parentId типичный вариант, который часто применяется для таких задач. Стоит еще рассмотреть Nested sets и его вариации с прекалькулироваными значениями. В качестве отправной точки https://en.wikipedia.org/wiki/Nested_set_model

и Вам спасибо за наводочку)

@blacky0x0 будет жить. Поприветствуем!

Привет. Есть таблица Calendar у которой есть ссылки на таблицы Employee и Company(поля соответсвенно называются employeeId и companyId одно из значений всегда null). Как сделать на уровне базы данных, что бы нельзя было создать записи в таблицы календарь где (пример companyId = 2 и employeeId = null 2) существуют 2 раза

то есть где две записи с одинаковыми companyId и employeeId ?

Привет. Есть таблица Calendar у которой есть ссылки на таблицы Employee и Company(поля соответсвенно называются employeeId и companyId одно из значений всегда null). Как сделать на уровне базы данных, что бы нельзя было создать записи в таблицы календарь где (пример companyId = 2 и employeeId = null 2) существуют 2 раза

наложить уникальность на сочетание (companyId, employeeId)

Привет. Есть таблица Calendar у которой есть ссылки на таблицы Employee и Company(поля соответсвенно называются employeeId и companyId одно из значений всегда null). Как сделать на уровне базы данных, что бы нельзя было создать записи в таблицы календарь где (пример companyId = 2 и employeeId = null 2) существуют 2 раза

А не стоит ли Вам разделить эту таблицу на две (когда появляются такие требования, это зачастую намекает на неправильную нормализацию)?

Привет. Есть таблица Calendar у которой есть ссылки на таблицы Employee и Company(поля соответсвенно называются employeeId и companyId одно из значений всегда null). Как сделать на уровне базы данных, что бы нельзя было создать записи в таблицы календарь где (пример companyId = 2 и employeeId = null 2) существуют 2 раза

Вы имели в виду как-то так? CREATE TABLE Calendar(empl_id int, company_id int, UNIQUE (empl_id, company_id)); CREATE UNIQUE INDEX ON Calendar(empl_id) WHERE company_id IS NULL; CREATE UNIQUE INDEX ON Calendar(company_id) WHERE empl_id IS NULL;

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

кроме триггеров можно как-то по-простому это делать?

@justvit будет жить. Поприветствуем!

Вы имели в виду как-то так? CREATE TABLE Calendar(empl_id int, company_id int, UNIQUE (empl_id, company_id)); CREATE UNIQUE INDEX ON Calendar(empl_id) WHERE company_id IS NULL; CREATE UNIQUE INDEX ON Calendar(company_id) WHERE empl_id IS NULL;

Спасибо большое

Вопрос только я сделал без этой части UNIQUE (empl_id, company_id))

Это же я так понимаю никак не повлияет?

кроме триггеров можно как-то по-простому это делать?

Конечно, нет — либо триггеры, либо вручную. (Да, если кто-то вспомнит про RULES — их очень не советуют, и не без причины.) Кстати, а как это у Вас так получается, что в любой вставке в табл1 есть вся информация для новой записи в табл2? ;)

Это же я так понимаю никак не повлияет?

Да я же вопрос задавал. ;) А почему не просто: CREATE TABLE Calendar(empl_id int UNIQUE, company_id int UNIQUE, CHECK (num_nulls(empl_id, company_id) = 1)); В таком случае? Что тут не так, как Вы хотели?

Конечно, нет — либо триггеры, либо вручную. (Да, если кто-то вспомнит про RULES — их очень не советуют, и не без причины.) Кстати, а как это у Вас так получается, что в любой вставке в табл1 есть вся информация для новой записи в табл2? ;)

Дефолтные настройки, на самом деле связь у них через третью таблицу

Дефолтные настройки, на самом деле связь у них через третью таблицу

В любом случае, другой "магии" для автоматической вставки у нас, вроде, нет...

В любом случае, другой "магии" для автоматической вставки у нас, вроде, нет...

Ну я на всякий случай уточнил, спасибо!

Да я же вопрос задавал. ;) А почему не просто: CREATE TABLE Calendar(empl_id int UNIQUE, company_id int UNIQUE, CHECK (num_nulls(empl_id, company_id) = 1)); В таком случае? Что тут не так, как Вы хотели?

CHECK (num_nulls(empl_id, company_id) = 1) не знаю как эту часть реализовать в sequalize в отличие от индексов

CHECK (num_nulls(empl_id, company_id) = 1) не знаю как эту часть реализовать в sequalize в отличие от индексов

Ну а сейчас Вы как реализовываете? Я имею в виду, что сейчас мешает кому-то вставлять дубликаты (без NULL, вроде (1,1) )?

Народ есть вопрос по постгре, никак ничего понять не могу, правильно ли запрос написал. В ней таблица estate_properties с домами, которые имеют номер улицы, название улицы итд. Из всего этого работает full text search который по строке адреса находит несколько нужных домов. Но тут есть другая таблица user_properties, куда юзер загрузил данные и там только колонка, которая содержит полный или нет адрес. Нужно сделать апдейт для каждой колонки в user_properties и вставить туда id из таблицы estate_properties который будет найден по full text search. Пробовал такой вариант и он отрабатывает 30 минут, хотя в таблице user_properties только 81 строка. UPDATE import_user_properties AS iup SET estate_hash = ep.estate_hash FROM estate_properties AS ep WHERE ep.address_fts @@ plainto_tsquery('english', iup.address) AND iup.estate_hash is null AND iup.address is not null AND NOT EXISTS (SELECT 1 FROM import_user_properties WHERE estate_hash = ep.estate_hash);

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

Народ есть вопрос по постгре, никак ничего понять не могу, правильно ли запрос написал. В ней таблица estate_properties с домами, которые имеют номер улицы, название улицы итд. Из всего этого работает full text search который по строке адреса находит несколько нужных домов. Но тут есть другая таблица user_properties, куда юзер загрузил данные и там только колонка, которая содержит полный или нет адрес. Нужно сделать апдейт для каждой колонки в user_properties и вставить туда id из таблицы estate_properties который будет найден по full text search. Пробовал такой вариант и он отрабатывает 30 минут, хотя в таблице user_properties только 81 строка. UPDATE import_user_properties AS iup SET estate_hash = ep.estate_hash FROM estate_properties AS ep WHERE ep.address_fts @@ plainto_tsquery('english', iup.address) AND iup.estate_hash is null AND iup.address is not null AND NOT EXISTS (SELECT 1 FROM import_user_properties WHERE estate_hash = ep.estate_hash);

C виду, Вы сделали CROSS JOIN import_user_properties и estate_properties, так что неудивительно. По крайней мере, я не вижу между ними связи в запросе...

C виду, Вы сделали CROSS JOIN import_user_properties и estate_properties, так что неудивительно. По крайней мере, я не вижу между ними связи в запросе...

кросс джойн?

объясните плес)

объясните плес)

А что тут объяснять? Вы попробуйте аналогичный SELECT, сколько записей получится?

А что тут объяснять? Вы попробуйте аналогичный SELECT, сколько записей получится?

сек, сейчас попробую

а хотя их и джойнить нечем

Коллеги, привет. Подскажите, кто-то пробовал перенести tablespace в новую БД ?

а хотя их и джойнить нечем

Вот я именно об этом. :) > хотя в таблице user_properties только 81 строка Значит, и аналогичный SELECT должен возвращать не более 81 строки (иначе UPDATE будет работать "как повезёт").

Вот я именно об этом. :) > хотя в таблице user_properties только 81 строка Значит, и аналогичный SELECT должен возвращать не более 81 строки (иначе UPDATE будет работать "как повезёт").

так в том и дело, что эти 81 нечем джойнить) Для каждой из них нужно найти по строке адреса через фтс нужную проперти

так в том и дело, что эти 81 нечем джойнить) Для каждой из них нужно найти по строке адреса через фтс нужную проперти

Да всегда есть чем JOIN-ить. ;) Тем не менее, можно использовать что-то вроде: UPDATE import_user_properties SET estate_hash = (подзапрос, возвращающий нужное property).

Да всегда есть чем JOIN-ить. ;) Тем не менее, можно использовать что-то вроде: UPDATE import_user_properties SET estate_hash = (подзапрос, возвращающий нужное property).

оо, сейчас попробую

@select_username будет жить. Поприветствуем!

Да всегда есть чем JOIN-ить. ;) Тем не менее, можно использовать что-то вроде: UPDATE import_user_properties SET estate_hash = (подзапрос, возвращающий нужное property).

написал подобное

запрос свалился на 300 секунд

и умер

там проблема еще, что в таблице estate_properties около 121 млн записей

Коллеги, привет. Подскажите, кто-то пробовал перенести tablespace в новую БД ?

А в чём вопрос?

и умер

Что такое "умер"? И, кстати, у Вас там LIMIT без ORDER BY — Вы уверены, что это нормально, т.е. под условия всегда подходит одна запись? > там проблема еще, что в таблице estate_properties около 121 млн записей Ну а индекс есть соотвествующий? Вы план запроса смотрели?

Что такое "умер"? И, кстати, у Вас там LIMIT без ORDER BY — Вы уверены, что это нормально, т.е. под условия всегда подходит одна запись? > там проблема еще, что в таблице estate_properties около 121 млн записей Ну а индекс есть соотвествующий? Вы план запроса смотрели?

там LIMIT 1 ато подзапрос возвращает множество записей для одного адреса. Например юзер записал в адрес "Los Angeles" то подзапрос вернет несколько млн. Нужно брать всегда первый. Это немного тупизм, но такое требование клиента. Он как ребенок хочет эту фичу

Что такое "умер"? И, кстати, у Вас там LIMIT без ORDER BY — Вы уверены, что это нормально, т.е. под условия всегда подходит одна запись? > там проблема еще, что в таблице estate_properties около 121 млн записей Ну а индекс есть соотвествующий? Вы план запроса смотрели?

Индексы есть. Сейчас еще раз перепроверю

там LIMIT 1 ато подзапрос возвращает множество записей для одного адреса. Например юзер записал в адрес "Los Angeles" то подзапрос вернет несколько млн. Нужно брать всегда первый. Это немного тупизм, но такое требование клиента. Он как ребенок хочет эту фичу

Эх... перечитайте то, что я написал. Без ORDER BY никаких "первых" не может быть!

Индексы есть. Сейчас еще раз перепроверю

в таблице уникальный на estate_hash и на фтс в таблице import_user_properties не уникальный на estate_hash и на address

Эх... перечитайте то, что я написал. Без ORDER BY никаких "первых" не может быть!

А почему сделать Order by

по какой колонке, ато я понять не могу

А почему сделать Order by

Это Ваше дело — откуда мне знать, какой порядок Вам нужен? ;)

Это Ваше дело — откуда мне знать, какой порядок Вам нужен? ;)

любой)))

в таблице уникальный на estate_hash и на фтс в таблице import_user_properties не уникальный на estate_hash и на address

Так Вы план запроса лучше покажите.

сек

любой)))

То есть Вас устраивает, что, например, каждое выполнение этого запроса будет давать разные результаты? ;) Дело Ваше, конечно...

То есть Вас устраивает, что, например, каждое выполнение этого запроса будет давать разные результаты? ;) Дело Ваше, конечно...

да) меня нет, но я предупредил клиента и ему норм.

кстати может дело в postgre сервере, пытаюсь что-то выполнить и он возвращает ошибку

через раз

1 раз выполнит какойнить SELECT а другой уже нет и пишет эту ошибку. Но само приложение, которое работает онлайн сейчас работает стабильно

может это интернет у меня не очень

А в чём вопрос?

Вопрос — возможно ли это? Насколько трудно? Стандартных утилит для этого нет, насколько я понимаю?

Парни, подскажите пожалуйста, при использовании pg_pathman, когда выполняем слияние партиций (merge_range_partitions), будут ли блокировки?

кстати может дело в postgre сервере, пытаюсь что-то выполнить и он возвращает ошибку

Ну а в логах PostgreSQL что-то есть по этому поводу?

Вопрос — возможно ли это? Насколько трудно? Стандартных утилит для этого нет, насколько я понимаю?

Эээ... так разве это работает не наоборот? Т.е. базы (их части) размещаются в tablespace-ах. А Вам это вообще зачем?

Ну а в логах PostgreSQL что-то есть по этому поводу?

сейчас буду смотреть все по порядку

Парни, подскажите пожалуйста, при использовании pg_pathman, когда выполняем слияние партиций (merge_range_partitions), будут ли блокировки?

есть тут кто из postgres pro ?)

Вопрос — возможно ли это? Насколько трудно? Стандартных утилит для этого нет, насколько я понимаю?

1. Возможно. 2. Не трудно. 3. Нет. Задачу какую решаете? Опишите подробнее. Недавно, кстати, переносил данные из одного кластера в другой, как раз с табличными пространствами, использовал для этого pglogical. Всё переносится, естественно, заранее, нужно накатить структуру баз данных кластера в новом расположении.

1. Возможно. 2. Не трудно. 3. Нет. Задачу какую решаете? Опишите подробнее. Недавно, кстати, переносил данные из одного кластера в другой, как раз с табличными пространствами, использовал для этого pglogical. Всё переносится, естественно, заранее, нужно накатить структуру баз данных кластера в новом расположении.

задача следующая: есть БД, с которой работают микросервисы. Данные каждого микросервиса лежат в отдельном tablespace. Возникла задача "распилить" единую БД по принципу "один микросервис — одна БД". Как это сделать?

Добавь тс, добавь туда файлы, перенеси данные в новую тс