@pgsql

Страница 670 из 1062
Darafei
08.02.2018
12:35:24
Привет вновьприбывшим!

aleksej
08.02.2018
12:35:26
Привет, подскажите как сделать partial index, который с условием where должен быть всегда пустым? типа уникальный содержит одну строку, а этот индекс всегда должен быть пустым

aleksej
08.02.2018
12:38:35
ну в where на самом деле комбинация, а не false

Google
aleksej
08.02.2018
12:38:54
реальная комбинация из полей таблицы

Alexander
08.02.2018
12:40:07
Идея в том, чтобы строка, которая удовлетворяет условию where была строго одна?

aleksej
08.02.2018
12:41:23
строго одна - это unique

нужно чтобы вообще таких строк не было

Evgeniy
08.02.2018
12:41:40
check constraint

Alexander
08.02.2018
12:41:45
+1

aleksej
08.02.2018
12:44:43
да, похоже это https://www.postgresql.org/docs/9.4/static/sql-createtable.html#SQL-CREATETABLE-EXCLUDE

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

Yaroslav
08.02.2018
12:45:49
спасибо очень буду читать, я думал constraint только для одной строки можно использовать
А зачем Вам больше, чем для одной строки в этом случае? Т.е. причём тут EXCLUDE?

aleksej
08.02.2018
12:48:20
в индекс по where может попасть несколько строчек, ограничение чтобы была только одна - это уникальность. Мне нужно чтобы индекс всегда был пустой

Evgeniy
08.02.2018
12:49:34
тебе не нужен индекс, тебе нужно чтобы строчек не было

уникальный индекс это просто структура данных которая энфорсит констрейнт

особенность реализации если хочешь

Google
Evgeniy
08.02.2018
12:50:18
если строчек быть не должно, то и индексировать нечего

отбрасывается на входе в табличку

aleksej
08.02.2018
12:54:07
check только к одной строке?

Evgeniy
08.02.2018
12:55:12
да

если нужно куда-то сходить еще посмотреть на данные для принятия решения пустить/непустить, то надо делать триггер

Alexander
08.02.2018
13:50:12
Ребят, всем добрый день. Как сделать выборку начиная с определенного значения .. т.е. мне нужно не offset применить а начать выборку начиная с определенного сообщения отсортированного потом по определенному параметру

Ilia
08.02.2018
13:51:05
WHERE, ORDER BY, OFFSET, LIMIT

Alexander
08.02.2018
13:56:14
И?

Alexander
08.02.2018
13:58:36
WHERE (col1, col2) > (const1, const2) ORDER BY col1, col2 LIMIT N;

Индекс по (col1, col2) будет хорошо юзаться

Оно?

Andrey
08.02.2018
13:59:06
Alexander
08.02.2018
14:00:33
То что вы описываете, называется value based пагинацией. Только вы обязательно должны сортировать по этому значению, иначе в чём смысл?
Или можно вначале выбрать нужную строку, получить из неё значение сортировки, а потом уже его использовать в WHERE.

Сергей
08.02.2018
14:05:23
Alexander
08.02.2018
14:21:19
Сортировать я буду по другому значению т.е. по дате. А начинать мне надо выборку со значения определенного с другого поля

определенное значение в поле это строка а не число

Andrey
08.02.2018
14:23:57
Сортировать я буду по другому значению т.е. по дате. А начинать мне надо выборку со значения определенного с другого поля
У вас в любом случае данные должны быть отсортированы по тому самому "другому полю" сначала, иначе получается абсурд.

Saidazim
08.02.2018
14:24:22
доброго времени суток, хотел сделать репликацию master-slave (раньше не делал, опыт пока нет по реплики) поискал материалы, хотел узнать ваши мнения какой из них лучше если есть хорошие примеры напишите буду рад любой отзыв https://losst.ru/replikatsiya-postgresql https://romantelychko.com/blog/1583/

Google
Denis
08.02.2018
14:37:21
Всем привет. Прошу прощения за краткий офтоп. В компанию ТекФорс требуется DBA (PostgreSQL), вилка зп - до 150К , но готовы вести индивидуальные переговоры и по более высоким запросам. Возможная локация - Москва, Питер, Самара. #работа #job #vacancy korotenko@tecforce.ru

Mikhail
08.02.2018
14:44:51
Ссылка на hh, остальное не надо сюда писать

Evgeniy
08.02.2018
14:45:24
да ладно, норм

Darafei
08.02.2018
15:16:33
Roman
08.02.2018
15:17:23
чем же лучше?

Ilia
08.02.2018
15:21:32
Чем в HH...

Alex
08.02.2018
15:24:02
как сконвертировать в timestamp результат SELECT '2018-01-29 01:00:00'::timestamp - '2018-01-21 23:00:00'::timestamp 0 years 0 mons 7 days 2 hours 0 mins 0.00 secs

Evgeniy
08.02.2018
15:28:04
postgres=# SELECT EXTRACT(epoch FROM ('2018-01-29 01:00:00'::timestamp - '2018-01-21 23:00:00'::timestamp)); date_part ----------- 612000

Lev
08.02.2018
15:28:04
Лучше в линкедин
он в РФ вроде как заблокирован

Evgeniy
08.02.2018
15:28:05
м?

Сергей
08.02.2018
15:36:45
Anton [Mgn, az09@osm]
09.02.2018
07:23:47
Обновление PostgreSQL 10.2, 9.6.7, 9.5.11, 9.4.16 и 9.3.21 http://www.opennet.ru/opennews/art.shtml?num=48043 Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL: 10.2, 9.6.7, 9.5.11, 9.4.16 и 9.3.21, в которых представлена порция исправлений ошибок. Выпуск обновлений для ветки 9.3 продлится до сентября 2018 г., 9.4 до декабря 2019 г., 9.5 до января 2021 г., 9.6 - до сентября 2021 года, 10 - до октября 2022 года. #opennet

Сергей
09.02.2018
15:40:01
@Komzpa спаси-сохрани

Mike Chuguniy
09.02.2018
17:47:44
Т.е. реально 10.3 в прод ставить ещё рановато.

Сергей
09.02.2018
17:53:59
10.3 ж тока вышла

Maksim
09.02.2018
17:55:08
Darafei
09.02.2018
17:57:55
почему рано, вы не бекапите что ли?

Google
Mike Chuguniy
09.02.2018
18:00:24
почему рано, вы не бекапите что ли?
Потому что ночью я хочу спать, а не судорожно восстанавливать БД из бекапа под разрывающийся от звонков телефон.

10.2, 10.3 нет
Вот я и говорю, с такими ошибками 10.3 в прод рано.

Сергей
09.02.2018
18:04:34
Да, опечатался

Maksim
09.02.2018
18:06:34
Вот я и говорю, с такими ошибками 10.3 в прод рано.
Предвкушаешь новые фиксы? Ошибки предыдущей минорной 10-ки исправлены

Mike Chuguniy
09.02.2018
18:07:56
Предвкушаешь новые фиксы? Ошибки предыдущей минорной 10-ки исправлены
А сколько новых добавлено? И сколько ещё не выявлено. Не, раньше 10.4 точно в прод нельзя.

И ничего я не предвкушаю, просто опыт.

Darafei
09.02.2018
18:11:22
пока жители Виллабриба ждут новых ошибок, жители Виллабаджо уже собрали все встреченные на своих ворклоадах и получили патчи!

Yaroslav
09.02.2018
18:25:21
А сколько новых добавлено? И сколько ещё не выявлено. Не, раньше 10.4 точно в прод нельзя.
Добавлено-то, скорее всего, мало. И всё равно можно оказаться в ситуации, когда будет спровоцирована именно Вашим приложением (т.е. никто другой до этого не наткнётся).

А как читать recycled сегменты WAL с помощью pg_waldump?

Alex
09.02.2018
23:30:52
А сколько новых добавлено? И сколько ещё не выявлено. Не, раньше 10.4 точно в прод нельзя.
пока 11 не выйдет 10 использовать нельзя. А лучше 12 %). Даже 9.6 использовать нельзя тк есть стабильная 9.2. Вообще, начинать релиз пользовать только когда он end of life уже. Баги новые уже точно не превнесут , а выявленные обходить костылями и велосипедами %)

Yaroslav
09.02.2018
23:33:33
Alex
09.02.2018
23:33:58
А вопрос то ж надо раскрыть

Yaroslav
09.02.2018
23:36:28
А что раскрывать-то? При попытке это сделать просто получается: pg_waldump: FATAL: could not find a valid record after 5/84000000

Просто делаю: pg_waldump 000000010000000500000084

Alex
09.02.2018
23:47:08
Просто делаю: pg_waldump 000000010000000500000084
Сейчас, например, если имя файла не отображает lsn, которые в нём есть возникает следующая ошибка: pg_xlogdump 0000000100000000000000A2 pg_xlogdump: FATAL: could not find a valid record after 0/A2000000 тогда как /pg_xlogdump 0000000100000000000000A1 rmgr: Heap len (rec/tot): 14/ 72, tx: 470598, lsn: 0/A1000E58, prev 0/A0FFEEE0, desc: HOT_UPDATE off 20 xmax 470598 ; new off 63 xmax 0, blkref #0: rel 1663/13322/16396 blk 5137 ... [postgres@thunder2 pg_xlog]$ ls -l 0000000100000000000000A2 rw------. 1 postgres postgres 16777216 Feb 1 14:46 0000000100000000000000A2 [postgres@thunder2 pg_xlog]$ ls -l 0000000100000000000000A1 rw------. 1 postgres postgres 16777216 Feb 1 15:03 0000000100000000000000A1 Происходит это из-за того что файл был уже циклически перезаписан новым wal, но имя при этом не было изменено. Наверое, было бы правильно чтобы при вызове pg_xlogdump вне зависимости от имени файла pg_xlogdump показывал информацию, которая содержится в данном файле. Сейчас утилита использует имя файла как отправную точку при поиске записей, что в случае с файлами из директории pg_xlog ведет к вышеуказанному поведению. Мы делали вродеб для этого патч, не очень в курсе уехал он в ванильную версию.

а вы точно в постгреспро работаете?
Думаете в пгпро не умеют шутить?

Evgeniy
09.02.2018
23:49:26
Думаете в пгпро не умеют шутить?
я думаю что там к сожалению не умеют пушить в апстрим

Google
Alex
09.02.2018
23:50:41

Страница 670 из 1062