Подскажите, а это нормальная ситуация, когда pg_basebackup не скопировал файл pg_control? Бэкап снимал со стендбая.

По идее, нет, не нормальная... Никаких ошибок pg_basebackup не выдавал? А какая версия PostgreSQL?

По идее, нет, не нормальная... Никаких ошибок pg_basebackup не выдавал? А какая версия PostgreSQL?

Не выдавал. 9.5.13.

Я уже запустил процесс заново. Так как по-видимому, нет способа нормально синкнуть данные.

Не выдавал. 9.5.13.

Может быть, на том standby, с которого снимали, что-то есть в логах?

получается запись в pg_hba.conf есть, но написано что нет.

Рестарт?

Рестарт?

не перезапускает. крашится и в логах вон то пишет.

разве последнее правило в hba не должно меня "пропустить"?

разве последнее правило в hba не должно меня "пропустить"?

Подними выше правило, в ipv4

Не из-за этого.

Почему-то через pcs resource restart pgsql нормальный перезапуск был и все заработало. А через service restart не работало.

А ну ок

По ходу если pcs resource стоит, то он запрещает делать перезапуск через обычный сервис. Нифига себе. Я час не догонял тоже.

Уважаемые знатоки, UPDATE t SET v=v создаёт новый тупл, внимание вопрос: нахуя так? И будет ли оно ломать HOT если поле проиндексировано?

есть такое https://www.postgresql.org/docs/10/static/functions-trigger.html

Я выключил мастер и слейв сейчас в режиме чтения работает.

https://habr.com/company/etagi/blog/314000/

может тут поможет. сам не работал с ним

подскажите, есть интервал к примеру "1 day 5 hour..." как его приобразовать, чтобы вывести колличество часов 29, если date_part('hour' ,my_interval ) он выдасть 5, а мне нужно всё что больше часов чтобы он преобразовал в часы...

подскажите, есть интервал к примеру "1 day 5 hour..." как его приобразовать, чтобы вывести колличество часов 29, если date_part('hour' ,my_interval ) он выдасть 5, а мне нужно всё что больше часов чтобы он преобразовал в часы...

спс, уже сам нашёл как...

спс, уже сам нашёл как...

Написал бы тогда решение)

extract(epoch from interval '1 day 5 hour')/3600

друзья, нужно секционировать таблицу добавив соответственно 500 секций писать 500 раз create table не хочется решение динамический sql ? p.s. есть вдруг пример может у кого ?)

друзья, нужно секционировать таблицу добавив соответственно 500 секций писать 500 раз create table не хочется решение динамический sql ? p.s. есть вдруг пример может у кого ?)

неименованный блок DO

И внутри - цикл.

неименованный блок DO

можно чуть больше подсказок?) неделю на постгрес

https://postgrespro.ru/docs/postgresql/10/sql-do

https://postgrespro.ru/docs/postgresql/10/sql-do

спасибо

друзья, нужно секционировать таблицу добавив соответственно 500 секций писать 500 раз create table не хочется решение динамический sql ? p.s. есть вдруг пример может у кого ?)

Учитывая: > можно чуть больше подсказок?) неделю на постгре Вот это: > друзья, нужно секционировать таблицу добавив соответственно 500 секций Вам почти наверняка не нужно.

500 это дискретное число

Ярослав, ну пусть человек помучается. Глядишь, в следующий раз думать будет.

@lestvt сколько записей в таблице? Начнём с этого.

@lestvt сколько записей в таблице? Начнём с этого.

0

Или, почему вы решили, что вам надо разбивать таблицу на части?

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

Ярослав, ну пусть человек помучается. Глядишь, в следующий раз думать будет.

Да вдруг это всё на чьём-то prodution происходит. ;) Как-то жалко, всё же...

> предполагается секционировать таблицу необходимо для избежания блокировок Каких блокировок?

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

У вас камеры же только вставляют данные? Так? Значит блокировок мешающих заливке данных быть не должно.

> предполагается секционировать таблицу необходимо для избежания блокировок Каких блокировок?

эксклюзивная блокировка намерений

IX на IX не ложится (sql server)

У вас камеры же только вставляют данные? Так? Значит блокировок мешающих заливке данных быть не должно.

500 источников пишут в 1 таблицу и никаких блокировок в postgresql ?

При изменениях данных блокируются только изменяемые записи. У вас вставляются новые данные, которые никому не видны до момента фиксации транзакции, как они могут быть заблокированы?

IX на IX не ложится (sql server)

Я бы Вам посоветовал, эээ (мягко говоря) сейчас же прекратить применять Ваши знания MS SQL к базам абсолютно другой архитектуры. ;) Во-первых, здесь этой проблемы просто нет. Во-вторых, партционирование здесь работает совсем не так, как там.

При изменениях данных блокируются только изменяемые записи. У вас вставляются новые данные, которые никому не видны до момента фиксации транзакции, как они могут быть заблокированы?

как мне думалось в postgresql вставка блокирует таблицу на все транзакции кроме select, отсюда идея секционирования

Я бы Вам посоветовал, эээ (мягко говоря) сейчас же прекратить применять Ваши знания MS SQL к базам абсолютно другой архитектуры. ;) Во-первых, здесь этой проблемы просто нет. Во-вторых, партционирование здесь работает совсем не так, как там.

хороший совет) пожалуй я им воспользуюсь

Я бы Вам посоветовал, эээ (мягко говоря) сейчас же прекратить применять Ваши знания MS SQL к базам абсолютно другой архитектуры. ;) Во-первых, здесь этой проблемы просто нет. Во-вторых, партционирование здесь работает совсем не так, как там.

Поддерживаю. Нужно начать с изучения архитектуры PG.

вы коллеги правы! но у нас релиз горит :DD бывали в таких ситуациях? ))))

как мне думалось в postgresql вставка блокирует таблицу на все транзакции кроме select, отсюда идея секционирования

Нет. У нас вообще нет эскалации настоящих блокировок, в отличие от. ;)

аригато!

вы коллеги правы! но у нас релиз горит :DD бывали в таких ситуациях? ))))

Верю, отчасти и понимаю) Только потом таким ребятам как я это всё поддерживать в проме. Ну пожалуйста, хотя бы первые 6 тем: https://postgrespro.ru/education/courses/DEV1

Верю, отчасти и понимаю) Только потом таким ребятам как я это всё поддерживать в проме. Ну пожалуйста, хотя бы первые 6 тем: https://postgrespro.ru/education/courses/DEV1

отдельная благодарность за полезное чтиво! обязательно прочту

Там и посмотреть можно, на YouTube. На скорости 1.25, 1.5 ;) Удачи!

Подскажите, пожалуйста. Нужен механизм UPDATE or INSERT. допустим таблица +---+---+----+ |id|c1|c2| +---+---+----+ |1 |'x'| 'y'| +---+---+----+ Псевдокод: :p0 = 'x' :p1 = 'y' :p3 = 'xx' :p4 = 'yy' IF EXISTS (SELECT * FROM table WHERE c1=:p0 AND c2=:p1) DO UPDATE SET c1 = :p3 AND c2 = :p4 ELSE DO INSERT INTO table (c1,c2) VALUES (:p3, :p4)

on conflict update

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

id мы же не вставляем

А у тебя могут вообще впринципе быть строки с одинакомым набором c1+c2 в этой таблице, которые каким-то другим способом туда попали?

извините, что встреваю

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

про пример выше

а что именно камеры пишут в БД&

?

Я бы Вам посоветовал, эээ (мягко говоря) сейчас же прекратить применять Ваши знания MS SQL к базам абсолютно другой архитектуры. ;) Во-первых, здесь этой проблемы просто нет. Во-вторых, партционирование здесь работает совсем не так, как там.

Насчёт того, что в Посгресе инсёрты не конфликтуют... Почитайте статью на Хабре как мы боролись с этими не конфликтующими блокировками: https://habr.com/company/postgrespro/blog/423685/

Нет. У нас вообще нет эскалации настоящих блокировок, в отличие от. ;)

Ну какие то блокировки все равно должны быть: туплы в страничке разместить, узел в индексе обновить

Здравствуйте!) https://www.db-fiddle.com/f/bniCCPTSwNrZAzrZXtJVnm/2 Подскажите, пожалуйста, как для такой структуры данных найти максимальное количество побед подряд для user_id 1? В данном случае результат должен быть 2, так как user_id 1 имеет флаг is_win = true для round_id= 1 & 2

Насчёт того, что в Посгресе инсёрты не конфликтуют... Почитайте статью на Хабре как мы боролись с этими не конфликтующими блокировками: https://habr.com/company/postgrespro/blog/423685/

Это же не "эти", разве нет? В статье по LWLocks, а я про "настоящие" tuple locks. А в MS SQL действительно есть не только lightweight, но и "настоящие" блокировки на запись, они хранятся в памяти, т.е. их количество ограничено, вследствие чего они могут укрупняться... с худшими последствиями, чем в PostgreSQL, в крайних случаях.

Ну какие то блокировки все равно должны быть: туплы в страничке разместить, узел в индексе обновить

Контекст вопроса был: "как мне думалось в postgresql вставка блокирует таблицу на все транзакции кроме select," Так что и ответ был про это. :)

Здравствуйте!) https://www.db-fiddle.com/f/bniCCPTSwNrZAzrZXtJVnm/2 Подскажите, пожалуйста, как для такой структуры данных найти максимальное количество побед подряд для user_id 1? В данном случае результат должен быть 2, так как user_id 1 имеет флаг is_win = true для round_id= 1 & 2

Попробуйте оконными функциями, пошагово — должно быть несложно.

Это же не "эти", разве нет? В статье по LWLocks, а я про "настоящие" tuple locks. А в MS SQL действительно есть не только lightweight, но и "настоящие" блокировки на запись, они хранятся в памяти, т.е. их количество ограничено, вследствие чего они могут укрупняться... с худшими последствиями, чем в PostgreSQL, в крайних случаях.

А в Посгресе есть relation extension lock, rкоторый "настоящий" лок, а не LWLock (хотя есть патч,. переписывающтй его на LW-Lock). Вот за него драка и идёт.