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

зачем тогда он вообще нужен?

но вообще пафман создавался изначально для оптимизации запросов (планирование, исполнение)

вы уже паритесь, отдавайте айдишники интами и сделайте нормальный АПИ

@lorddaedra Не в коем случае не отдавайте интами, пусть булет id pk, и public_id uuid. uuid наружу, а семантику не скрывайте, как подсказал @Komzpa (сами потом огребете проблем это расшифровывать). uuid чтобы вас не перебирали.

uuid чтобы скрыть, сколько данных в базе и как активно используют проект (например, это позволит чуть-чуть приукрасить и никто не проверит, а если будут id - всё будет легко проверить) я тут подумал, что можно обойтись без отдельной таблицы, у меня uuid1 и там последний блок - указание на ноду, но так как работает всё в докер-контейнерах, там так или иначе этот указатель ноды будет меняться при перезапуске, я подумал, что могу генерить этот ид ноды самостоятельно и кодировать там название таблицы

это позволит просто во все таблицы добавить uuid поле и не делать отдельную

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

я не понимаю, чем вас table/uuid не устраивает. Зачем это кодирование

а указатель на ноду - это вообще шиза

если система не распределенная

uuid чтобы скрыть, сколько данных в базе и как активно используют проект (например, это позволит чуть-чуть приукрасить и никто не проверит, а если будут id - всё будет легко проверить) я тут подумал, что можно обойтись без отдельной таблицы, у меня uuid1 и там последний блок - указание на ноду, но так как работает всё в докер-контейнерах, там так или иначе этот указатель ноды будет меняться при перезапуске, я подумал, что могу генерить этот ид ноды самостоятельно и кодировать там название таблицы

смотришь статистику по таблицам и не паришься

она распределённая, контейнеры на разных серверах в докере, просто getnode() всё равно кривой по умолчанию, там при каждом рестарте контейнера будет уже другой указатель ноды

( https://docs.python.org/3.7/library/uuid.html#uuid.uuid1 )

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

спасибо)

можно getnode() написать свой: первые 10 цифр - SHA512 от hostname'а сервера, оставшиеся 2 (256 вариантов), допустим, кодируют название таблицы

Vsem privet

na rabote perepad pitaniya bilo nochyu, teper v baze na nekotorie tablici i metodi oshibku vidaet

SQL atate: 58030

Eto kod oshibki

Ya tak dumayu problema s pamatyu, fayli poxodu povredilis pri perepade

Chto mojno s etim sdelat?

можно getnode() написать свой: первые 10 цифр - SHA512 от hostname'а сервера, оставшиеся 2 (256 вариантов), допустим, кодируют название таблицы

и при запуске докер-контейнера передавать hostname ноды, где он там запущен (или, возможно, оно там и так уже есть, я не помню)

Mojet kto stalkivalsya?

vse normalno ya govoru po ihnemy. Net ne СTaJIKuBaJIc9|

Он же пишет по русски - 58030 io_error, бекап настало свое время

Еще можно проверить права доступа, диск, все ли примонтировалось и не read only

Он же пишет по русски - 58030 io_error, бекап настало свое время

Только бекап? Я думал может есть другие варианты

Был тут один парень - у него много таблиц повреждено.. Вроде что-то он восстановил... Но есть вопросы к целостности данных

Бэкап - лучший )

Бэкап - лучший )

)) Так теряю данные на 2 дня

ну сморя какая база

ну сморя какая база

9.3

я про назначение.

250-300 Гб

мож у него биллинг

мож у него биллинг

Почти, но не совсем

Смс рассылки

600-800 Тыс нужных записей в день((

Карма. Проще всего бекап на вторую базу и потом догнать данные ил того что записалось за два дня.

смс спам? не. тогда пусть подыхает

Просто база не полностью повреждена, только некоторые части

смс спам? не. тогда пусть подыхает

Да нет

Походу бекап(((

Спасибо всем

стендбая нет?

ну как. как минимум 2 способа вернуть в работу это говно есть

но я против всяких там смс рассылок.

но я против всяких там смс рассылок.

Смс можно отправлять как спам, а можно и по согласию

У мну не спам

В защиту товарища, они и легальные так-то есть

да, только птичка "согласен" появляется везде почему-то самопроизвольно )

это вопрос не к оператору, оfftop кончился. Я б еще позлорадствовал по поводу частоты бекапов, но в послденее чп остался с бекапом 5 дневной давности :D

для начала сопоставьте следующее: СМС и 600 000 - 800 000 записей в ДЕНЬ. И это при том, что чел не моб. опер., а какой-то там прожект частный... Ну, и? Все совпало по "легальности рассылок"? (вот такиие мысли в слух)

да, только птичка "согласен" появляется везде почему-то самопроизвольно )

Рассылки бывают и внутри корпораций ?

Благо разрешение дает начальство

для начала сопоставьте следующее: СМС и 600 000 - 800 000 записей в ДЕНЬ. И это при том, что чел не моб. опер., а какой-то там прожект частный... Ну, и? Все совпало по "легальности рассылок"? (вот такиие мысли в слух)

Компания официальная и работает с операторами моб. по официальному договору. надеюсь совпало по легальности ☺️

практически ))) Теперь понятно, что в цепочке 600к-800к учавствует некий моб. оператор. ))) К слову, ему, оператору, только на руку подобная активность СМС... денюжка жежЪ )))

практически ))) Теперь понятно, что в цепочке 600к-800к учавствует некий моб. оператор. ))) К слову, ему, оператору, только на руку подобная активность СМС... денюжка жежЪ )))

Nu da )))

??

Есть такой вопрос. Любые данные хранятся в ячейках памяти. При перепаде напряжения, я думаю, сломались некоторые из них. Из-за чего и выдает ошибку. Можно ли как-то переписать данные в другие ячейки памяти посредством Postgres

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

Никто не в курсе?

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

ERROR: S client not available

не все, разумеется, а лишь те, что "запоролись"...

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

Бля, главное в таблицах все есть, показывает, вот при вызове методов, которые используют эти таблицы выдает ошибку((

делай дамп.

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

делай дамп.

Восстановление из бэкап?

угум-с

данные, если они РЕАЛЬНО актуальные - важнее!

их дампом

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

забить нулями проблемную страницу не подходит?

ключевые слова postgresql page zeroing

забить нулями проблемную страницу не подходит?

да врядли

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

походу так и буду в конечном итоге

это как вариант. подумай еще, может более изящный подход "придумается" )

C pg_probackup работали есть подводные камни? А то я мамонсу завел и у него два с половиной пользователя видимо :(

это как вариант. подумай еще, может более изящный подход "придумается" )

select relname from pg_class where relfilenode = 219676568; Короче, может кому понадобится. Узнал этим запросом название таблицы, к которой принадлежит поврежденный файл, и уже восстановил нужную таблицу.

Спасибо всем кто не поленился помочь

select relname from pg_class where relfilenode = 219676568; Короче, может кому понадобится. Узнал этим запросом название таблицы, к которой принадлежит поврежденный файл, и уже восстановил нужную таблицу.

+ ?

+ ?

Thank you

otdelno

otdelno

لا شكر على واجب ? ?

Уважаемые, подскажите пожалуйста, какие подводные камни могут быть в подобном, хмм, странном, варианте: http://lpaste.net/357996 Мне нужно атомарно либо обновить "документ" с сохранением предыдущего значения, либо добавить новый "документ", если его ранее не было. Upsert мне тут не поможет - версия 9.4. Вообще, этот вариант работает и на первый взгляд корректно (там trace, для отладки вставленные, показывают, что лишние "ветки" не исполняются), но всё же немного страшновато. А вообще, если сие переписать на PlPgSQL в императивном стиле, оно получится куда логичнее, но, по идее, будет сильно менее эффективно.

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

Не проще ли сразу скидывать версии в таблицу лога, триггером или вручную обновляя основную таблицу, и повторять при возникновении конфликта в результате гонки?

Если честно, не хочу триггеры городить. Плюс, тут ещё планируется ветка для "виртуальных" документов, которые не хранятся в documents, а обрабатываются внутри отдельных функций, так что подобную функцию так или иначе городить придётся. Можно навешать rules-ы, но это уже другая история...

И, кстати, вопрос ещё, что будет более эффективно - такой вот вариант или отдельные триггеры. Кстати, эта функция security deriner (чтоб отрезать всем прямой доступ к таблицам).

Ну портянки процедур конечно интересней триггеров

Мне, в общем-то, интересны именно "подводные камни" подобного подхода. Больше для академических целей, нежели для решения конкретной задачи:) Подобного я ещё не использовал.

Кстати, если честно, никогда не понимал смысла в update после конфликта insert-а - оно же неэффективно должно быть, ибо подразумевает отлов exception-а

Вот в доке по PlPgSQL: Tip: A block containing an EXCEPTION clause is significantly more expensive to enter and exit than a block without one. Therefore, don't use EXCEPTION without need.

Притом, думаю, по статистике update должны происходить в среднем чаще insert-ов, а классический до-9.5-ый "upsert" через отлов exception-а подразумевает insert на _каждую_ трансакцию.