и как бы я не на SO пришел чтобы за меня задачу решили

одновременного обновления данных, по которым строится отчет?

поясни плиз

Ребят, нужен ваш совет по постгресу(9.6) Есть веб-сервис ненагруженный и из него периодически делается большой отчет, который минут 10 генерится. Отчет не на sql, а в питоне сделан. много запросов. И есть такая проблема - за то время, пока он генерится что-то меняется в базе и отчет становится неверным. Все транзакции сейчас read commited. Есть иде обернуть генерацию отчета в serialisable. Отчет это readonly операция. Судя по документации, это норм. 2 вопроса - 1)могут ли обычные транзакции или сам отчет упасть с serialization anomaly? (вроде нет, но не уверен) 2) видити ли вы какие-то подводные камни в этом рещении?

1. скорее всего не могут, но будут падать; 2. сначала выгрести из БД все данные, потом развлекаться с ними, как уже сказали, если невозможно свести кучу запросов к одному. Если свести в один - это проблематично, то сократить количество запросов, я думаю, возможность есть.

Я беспокоюсь за следующий случай: - Отчет начинает транзакцию - Юзер обновляет запись А - Отчет запрашивает запись А Или наоборот: - Отчет начинает транзакцию - Отчет запрашивает запись А - Юзер обновляет запись А, но транзакция отчета еще не закончилась Serializable - это уровень, которые предполагает, что транзакции работают с одними и те же данные строго последовательно, не допуская одновременного доступа. Следовательно, здесь возникает возможность для движка закрашить транзакции, описанные выше. В то же время параграф из доки выше утверждает, что все работает немного не так, как я думаю, поэтому здесь есть неопределенность.

Кстати, если вы действительно только читаете данные, используйте read only транзакции.

Ленин защищает пусек: diak_kuraev http://diak-kuraev.livejournal.com/1684319.html

Ребята, в чем может быть проблема. Из pgsql по логину и паролю могу зайти на базу, из pgadmin по логину и паролю - нет

а порт наружу слушает? а то заходишь, небось, по локальному сокету

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

удаленный сервер, не на моем компе

а, все, зашел :)

а, все, зашел :)

что было? в пгадмине ссл галку не поставил?))

что было? в пгадмине ссл галку не поставил?))

в pgadmin не указал DB :)

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

Ребят, нужен ваш совет по постгресу(9.6) Есть веб-сервис ненагруженный и из него периодически делается большой отчет, который минут 10 генерится. Отчет не на sql, а в питоне сделан. много запросов. И есть такая проблема - за то время, пока он генерится что-то меняется в базе и отчет становится неверным. Все транзакции сейчас read commited. Есть иде обернуть генерацию отчета в serialisable. Отчет это readonly операция. Судя по документации, это норм. 2 вопроса - 1)могут ли обычные транзакции или сам отчет упасть с serialization anomaly? (вроде нет, но не уверен) 2) видити ли вы какие-то подводные камни в этом рещении?

Repeatable Read в постгрессе - это на самом деле Snapshot Isolation (SI). Он видит снимок базы данных на момент начала транзакции. Serializable в постгрессе - это Serializable SI - тот же Snapshot Isolation, но с детектом "возожных аномалий". Просто readonly Serializable может привести к откату какой-нибудь транзакции, т.к. снимок, взятый этой транзакцией, может быть не вполне serializable. Есть специальный Serializable Read Only Deferrable - он дожидается возможности взять гарантированно сериализуемый снапшот. Т.о. это специальный режим для аналитических read-only транзакций.

С другой стороны, если у вас везде read committed, то скорее всего, вам не важна строгая сериализуемость. И тогда repeatable read удовлетворит простому требованию "даннвые не должны менятся"

спасибо всем за советы

@Komzpa, @pasha_golub хулиганы зрения лишают!

@Komzpa, @pasha_golub хулиганы зрения лишают!

Наподдали им

Спасибо, добрый человек!

в слаке gisdevs ребята нарисовали стейт карты "всё тормозит из-за автовакуума"

Жаль всех на карте

@Komzpa

Дай ссылку на чат

Я щас тоже занимаюсь гисами в том числе

Ты в Москве кстати ?

Давай митап сделаем по postgis

В этом чата 1234 человека!!! Прямо от сюда аудитория скорее всего наберется

я в Минске, и мы тут делаем митап по гисам :)

Дай ссылку на чат

http://thespatialcommunity.org/

Давай митап сделаем по postgis

впрочем, почему нет. кто ещё хочет митап про постгис? :)

http://thespatialcommunity.org/

(y)

впрочем, почему нет. кто ещё хочет митап про постгис? :)

я хочу. пока правда не знаю зачем :)

Давай митап сделаем по postgis

16 сентября будет Схемотехника, можно туда вписаться http://shtosm.ru/all/bolshaya-shemotehnika/ как раз суббота, удобно из других городов подтягиваться :)

Схемотехника. Мылорушникам надо популярно объяснить, что слова "схемотехника" и "географические карты" вводят в заблуждение и последующий ступор. А так - я бы послушал про постгис.

послушать да погнобить название много кто может. кто рассказать хочет? :)

послушать да погнобить название много кто может. кто рассказать хочет? :)

На задних рядах шепоток: - Заваливает, гад! (с) старый анеХдот.

:)

Схемотехника. Мылорушникам надо популярно объяснить, что слова "схемотехника" и "географические карты" вводят в заблуждение и последующий ступор. А так - я бы послушал про постгис.

В РФ почти все рисуют схемы местности. Потому что на картографическую деятельность надо получать лицензию.

А кто готов доехать до Минска ради митапа по postgis? =)

добрый день, есть бекап сделанный usr/pgsql-9.2/bin/pg_dump -Fc —username "postgres" —role "openerp" —no-password —blobs —encoding UTF8 —verbose —file "/home/backupscript/dbbackup-$date.backup" "cito" при восстановлении выдает ошибку : pg_restore -d cito_2017_06_05 /home/backupscript/dbbackup-20170806.backup pg_restore: [archiver] unsupported version (1.12) in file header

версии [root@OpenERP-CITO ~]# pg_dump —version pg_dump (PostgreSQL) 8.4.20 [root@OpenERP-CITO ~]# pg_restore —version pg_restore (PostgreSQL) 8.4.20

pgsql-9.2

kom@junocat ~ % pg_dump --version pg_dump (PostgreSQL) 9.6.3

psql (8.4.20, server 9.2.7) понятно

а как исправить? ?

ты пытаешься пользоваться софтом 2009 года :)

обнови стандартным для своего дистрибутива способом

ERROR: S client not available

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

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

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

и потом только перенести все на новую версию

@Komzpa можно только pg_dump и pg_restore обновить? и как ?

чтоб сервер пока не трогать

мы даже не знаем, что у тебя за система, кроме того, что она из ~2009 года

centos 5

наверно

centos 6.2

postgresql 9.2

мы даже не знаем, что у тебя за система, кроме того, что она из ~2009 года

а какая собственно разница-то? :) чтобы pg рулить необходимо еще и знать как каждый дядя вася pg собирает у себя в гараже?

а какая собственно разница-то? :) чтобы pg рулить необходимо еще и знать как каждый дядя вася pg собирает у себя в гараже?

"как обновить" подразумевает незнакомство со своим пакетным менеджером

мало того что пакетный меджер накладывает свои особености (после обновления пакета - рестарт СЕРВЕРА) так еще и подсовывают свои перлоговяхи

хм интересно ... попробовал : /usr/pgsql-9.2/bin/pg_restore -d db_2017_06_07 /home/backupscript/dbbackup-20170806.backup

начал возобновление

значит, у тебя полтора постгреса в системе и неплохо бы старый вычистить

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

можно как-то уднать чем занимается pg_restore в данный момент ? просто он у меня востонавливает базу и уже 15 минут как замерз на 8187 MB, база должна возобновиться до 16GB, проверяю размер : select t1.datname AS db_name, pg_size_pretty(pg_database_size(t1.datname)) as db_size from pg_database t1 order by pg_database_size(t1.datname) desc;

htop / iotop / poor man's profiler?

1 процесс postgres : postgres db_test [local] CREATE INDEX 2 процесс сам pg_restore

значит он ставит так долго индексы,спасибо

уже 43 минуты

crosstab?

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