> Pavel Golub removed Yet Another Stats ?

> Pavel Golub removed Artur Alimgulov

> Pavel Golub removed Artur Alimgulov

Да, слушаю вас внимательно

Просто предсказываю логичный шаг - бороться с причиной, а не следствием

Так уже ?

господа, а у кого-нибудь под рукой есть какой-нибудь готовый инструмент, способный разложить всю базоньку на кучу отдельных ddl'ных sql'ек, а не в один файл дампа всего ddl за раз?

господа, а у кого-нибудь под рукой есть какой-нибудь готовый инструмент, способный разложить всю базоньку на кучу отдельных ddl'ных sql'ек, а не в один файл дампа всего ddl за раз?

https://github.com/omniti-labs/pg_extractor

http://pastebin.com/xJzxz5mu

нужно поменять на свою базу и пользователя и будет успех

а нельзя просто после дампа разбить любой утилитой по знаку ";" ?

нет, конечно

как минимум по ';\n', и то, если в данных такого нет

;\n - это если тексты храничть в БД

вряд ли таких таблиц огромно количество

банально разбиваем на файлы делаем cat *.sql > out.sql Запускаетм out.sql локально смотрим если нет ошибок значит все хорошо

я вот точно знаю что Jdbc Драйвер делит по точке с запятой запросы

я вот точно знаю что Jdbc Драйвер делит по точке с запятой запросы

SELECT 'value1;value2;value3'; А тут как быть?

счас проверим

даже интересно стало

а что там проверять, никто не делит просто по ;

я как давно исходники драйвера ковырял

Оффтопик :)

DO $$DECLARE r record; BEGIN FOR r IN SELECT table_schema, table_name FROM information_schema.tables WHERE table_type = 'VIEW' AND table_schema = 'public' LOOP EXECUTE 'GRANT ALL ON ' || quote_ident(r.table_schema) || '.' || quote_ident(r.table_name) || ' TO webuser'; END LOOP; END$$;

И вот еще пример живой

Тут вообще бесполезно. Тут нужен парсер полноценный

+

Таще таки да парсер в jdbc встроенный

и выполняются запросы отдельно

Вопрос. Как написать запрос, чтобы индекс не дублировался Проще говоря при выполнении CREATE INDEX CONCURRENTLY on mods_monitoring (md); CREATE INDEX CONCURRENTLY on mods_monitoring (md); Создается 2 идентичных индекса

Явно указывать имя, например.

указывать имя и if not exists

ясно. благодарю. я чегой-то никогда особо не заморачивался с именами. Оказывается зря

ещё вопрос. при удалении индекса - есть возможность указать удалять каскадно. Я мозгом том то понимаю что он не будет удалять данные (теоретически), но тогда зачем параметр cascade?

ещё вопрос. при удалении индекса - есть возможность указать удалять каскадно. Я мозгом том то понимаю что он не будет удалять данные (теоретически), но тогда зачем параметр cascade?

Индекс может быть системным. Созданным в результате объявления CONSTRAINT

то есть по дефолту нужно каскад добавлять в конце?

нужно = рекомендуется

нужно = рекомендуется

Исходя из задачи и модели вашей

ALTER TABLE distributors ADD CONSTRAINT dist_id_zipcode_key UNIQUE (dist_id, zipcode); Создаст системный индекс по двум полям

Системный = автоматически создаст

хе

доку не ту смотрю в 9.1 нет

посвежее доки открой

9.5 например

Еще вопрос, который крутится со вчерашнего дня. Почему бы не указывать при создании индекса всегда CONCURRENTLY Есть радикальные отличия, кроме блокировки таблицы?

работает медленнее

То есть на продакшне обязательно чтобы параметр был, а вот в локали - лучше, чтобы не был.

Правильно?

Еще вопрос, который крутится со вчерашнего дня. Почему бы не указывать при создании индекса всегда CONCURRENTLY Есть радикальные отличия, кроме блокировки таблицы?

Нельзя в транзакции указывать CONCURRENTLY.

Я с транзакциями не работал. Как понял это что-то типа отложенных запросов и пока не понял как их юзать, даже не лез

Ну как бы раз не понимаю - не использую ?

Я с транзакциями не работал. Как понял это что-то типа отложенных запросов и пока не понял как их юзать, даже не лез

Транзакции обспечивают атомарность.

А щас будет вопрос - А что такое атомарность? ))

Тогда сразу и консистентность ))

))) неа.

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

https://ru.wikipedia.org/wiki/ACID

Тогда сразу и консистентность ))

ACID и в гугол

Или так ? но можно напугать

А щас будет вопрос - А что такое атомарность? ))

Если конечно ничем не отличается от понятия в программировании. Операция, которая либо выполняется, либо нет (если кратко)

Если конечно ничем не отличается от понятия в программировании. Операция, которая либо выполняется, либо нет (если кратко)

Либо откатывается.

верно. Проще говоря - либо return true и сохранение, либо false и ничего

ERROR: S client not available

https://blog.2ndquadrant.com/create-index-concurrently/

Тогда сразу и консистентность ))

А вот это как-бы эволюционно дохожу, но детально никогда не ковырял. Целостность же сейчас обеспечивается связями и гарантией СУБД о том, что данные не сотрутся при крахе системы

https://blog.2ndquadrant.com/create-index-concurrently/

За это спасибо, сегодня почитаю

А вот это как-бы эволюционно дохожу, но детально никогда не ковырял. Целостность же сейчас обеспечивается связями и гарантией СУБД о том, что данные не сотрутся при крахе системы

https://vladmihalcea.com/2014/01/05/a-beginners-guide-to-acid-and-database-transactions/

За это спасибо, сегодня почитаю

Не за что. CONCURRENTLY не всегда может завершиться успешно. Вообще статья интересная

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

Верно?

это самый распростаненный пример

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

про транзакции https://www.youtube.com/watch?v=QU2PVSnBGEY&index=2&list=PLaFqU3KCWw6JgufXBiW4dEB2-tDpmOXPH

В ACID - за Durability отвечает postgres. Или разрабу тоже думать надо?

если не autocommit=true То разрабу тоже

по необходимости

Ну судя по тому что опция существует, наверное автокоммит порой отключают :)

автокомит тут ни при чём

автокомит тут ни при чём

разрабу тоже думать надо?

?

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

все забывают про часть "или говорить, что не попали"

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

разрабу тоже думать надо?

man acid

То есть мгновенное прерывание операций с БД

все забывают про часть "или говорить, что не попали"

да-да )

Получается что, если транзакция попала в БД, за остальное отвечает СУБД. А не попасть она может только если бэкенд не смог отправить информацию

Тут я как понимаю накопление информации выполняется.

Но ведь в идеале (не факт конечно) легче развернуть бд рядом с бэкендом для накопительных оопераций и еее синхронизировать с основной бд

Или я не прав?

есть же синзронизация в постгрис

сейчас почитал - репликация по научному :)

нет, обычно, если приблизительно, то СУБД ведут журнал транзакций на случай сбоя, вот можно настроить чтоб commit отдавал ок только тогда когда данные были записаны (с вариантами) или не записаны (сбрасываются на диск пачками) и в последнем случае вы получаете ок, но уходите по питанию и все, даных нет

сейчас почитал - репликация по научному :)

она нужна для защиты от аппаратного сбоя