master - 9.6.5 slave - 9.6.10

Обновили бы Вы мастер... Да, значение в мс.

Обновили бы Вы мастер... Да, значение в мс.

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

Ребят, соьираю метрики с pg_stat_statements, там выводится у меня самые продолжительрые запросы. Можно ли кактт получить юзера кто выполнял их?) Как ч понял там этт не хранится

там есть поле userid

9.6.что? Вообще, это wal_sender_timeout, но странновато как-то...

параметр помог, спасибо большое ?

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

не со всем так, новая реплика подымается в другом ДЦ для переезда ?

А как можно проще вставить 100 000 строк с инкрементом по одному полю? id | number

А как можно проще вставить 100 000 строк с инкрементом по одному полю? id | number

COPY

кто может объяснить зачем опция analyze-in-stages после pg_upgrade если сам pg_upgrade делает vacuum и freeze (как минимум 9.5)

а он делает analyze?

кто может объяснить зачем опция analyze-in-stages после pg_upgrade если сам pg_upgrade делает vacuum и freeze (как минимум 9.5)

Хмм... а Вы уверены, что он делает VACUUM (что-то я такого не помню... или что конкретно Вы имеете в виду)? Ах да, опция затем, что ANALYZE-то он не делает, а статистика при pg_upgrade выбрасывается.

а он делает analyze?

https://github.com/postgres/postgres/blob/REL9_5_STABLE/src/bin/pg_upgrade/pg_upgrade.c#L249

Хмм... а Вы уверены, что он делает VACUUM (что-то я такого не помню... или что конкретно Вы имеете в виду)? Ах да, опция затем, что ANALYZE-то он не делает, а статистика при pg_upgrade выбрасывается.

^^^

^^^

Это делается при подготовке нового кластера, до "переливки" данных (почитайте, откуда вызывается prepare_new_cluster).

Это делается при подготовке нового кластера, до "переливки" данных (почитайте, откуда вызывается prepare_new_cluster).

Ооок

@Kozminykh будет жить. Поприветствуем!

@MatveyF будет жить. Поприветствуем!

@Sanberg будет жить. Поприветствуем!

@shi_tsu будет жить. Поприветствуем!

@ora_dba будет жить. Поприветствуем!

@Habuvo будет жить. Поприветствуем!

Привет! А подскажите nested transaction как реализовать в go - postgre (pq gorm)? я пробовал чистый скуэль получаю pq: unexpected transaction status idle, горм тем более такое не умеет Задача выполнить (или нет) ряд апдейтов не трогая внешнюю транзакцию

Я пытаюсь понять - это проблема драйвера или надо как то по особому оформить начало вложеной транзакции?

@dmitry_soloma будет жить. Поприветствуем!

@Bartymaeus будет жить. Поприветствуем!

Aikidos будет жить. Поприветствуем!

Я не знаю Оракл, поэтому не в курсе, что точно делаеьт dbms_alert.signal, но в Постгресе есть механизм LISTEN/NOTIFY, который возможно поможет решить ту же задачу

Я не знаю Оракл, поэтому не в курсе, что точно делаеьт dbms_alert.signal, но в Постгресе есть механизм LISTEN/NOTIFY, который возможно поможет решить ту же задачу

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

Привет! А подскажите nested transaction как реализовать в go - postgre (pq gorm)? я пробовал чистый скуэль получаю pq: unexpected transaction status idle, горм тем более такое не умеет Задача выполнить (или нет) ряд апдейтов не трогая внешнюю транзакцию

Вообще для такого в SQL используются SAVEPOINTs (на них же основаны exceptions в server-side programming languages), а что там в этой ORM — кто его знает...

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

Ну встроенного такого механизма в Посгресе нет... Возможно есть extension-ы. Надо искать.

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

Нотификацию кому/куда/как? ;)

Всем привет. Я, так-то, девелопер. Но тут возник вопрос по базам и понеслась.. pq: syntax error at or near \"T00\" Постгрес не любит даты вида 2017-01-01T00:00:00?

Всем привет. Я, так-то, девелопер. Но тут возник вопрос по базам и понеслась.. pq: syntax error at or near \"T00\" Постгрес не любит даты вида 2017-01-01T00:00:00?

нет, почему же, нормально относится. А что у вас там с кавычками и типами?

select '2017-01-01T00:00:00' :: timestamp;

тип поля какой?

он и дату из этого сделает

На самом деле тут все не так просто.. Если очень вкратце: есть некий датапайплайн. 1. Один учатсник делает селект. И кладет как JSON в кафку. 2. Подписчик кафки достает JSON, преобразует в Go-структуру и.. Думаю, будет проще, если я скину, как выглядит дата в JSON и как я это все дело вставляю в пг

Если опустить все, что я сказал выше и прийти к сути

some_column = to_timestamp(null, 'YYYY-MM-DD HH24:MI:SS.MS')

Значение берется из JSON, иногда это null, иногда дата в кавычках

updated_at = to_timestamp('2018-09-05T23:33:48Z', 'YYYY-MM-DD HH24:MI:SS.MS')

И, судя по всему, когда после даты идет нулевое время, все - умираем

И, судя по всему, когда после даты идет нулевое время, все - умираем

Лучше конкрентный пример покажите. И, кстати, какая версия PostgreSQL (мне помнится, что в чём-то связанном с преобразованиями timestamps исправляли какие-то ошибки не так давно, если не вру)?

Лучше конкрентный пример покажите. И, кстати, какая версия PostgreSQL (мне помнится, что в чём-то связанном с преобразованиями timestamps исправляли какие-то ошибки не так давно, если не вру)?

deleted_at = to_timestamp('2018-09-05T00:00:00Z', 'YYYY-MM-DD HH24:MI:SS.MS')

deleted_at = to_timestamp('2018-09-05T00:00:00Z', 'YYYY-MM-DD HH24:MI:SS.MS')

У меня всё работает (на 10.5). Так какая версия?

У меня всё работает (на 10.5). Так какая версия?

PostgreSQL 9.6.6

PostgreSQL 9.6.6

А timezone сессии, на всякий случай?

А timezone сессии, на всякий случай?

UTC

А timezone сессии, на всякий случай?

Если Вы об этом

Если Вы об этом

Да, об этом. Всё равно Ваш пример работает на 10.5.

PostgreSQL 9.6.6

А почему бы Вам просто не попробовать обновиться?

А почему бы Вам просто не попробовать обновиться?

БД заведуют господа американцы. Я лишь скромный девелопер. У них там свои датацентры и свои приколы

deleted_at = to_timestamp('2018-09-05T00:00:00Z', 'YYYY-MM-DD HH24:MI:SS.MS')

а зачем вы формат даты указываете? так просто не работает: deleted_at := '2018-09-05T00:00:00Z'::timestamptz; ?

БД заведуют господа американцы. Я лишь скромный девелопер. У них там свои датацентры и свои приколы

Ваши "господа американцы" уже пропустили как бы не пару CVE, не говоря уже о bugfix-ах (последняя версия — 9.6.10). :( Это хреновое администрирование, честно говоря.

Ваши "господа американцы" уже пропустили как бы не пару CVE, не говоря уже о bugfix-ах (последняя версия — 9.6.10). :( Это хреновое администрирование, честно говоря.

Вы правы. Скажу больше - недавно возникла интересная проблема. Мы доставали записи из MSSQL и клали в PG. Оказалось, что в некоторых строковвых полях в MSSQL были нулевые байты. И pg не мог их вставить, ругался на /u000 Когда мы сообщили DBA о том, что у нас такая проблема, их ответ был прост: "А вы добавьте NULLIF"

Данные так и остались с нулевыми байтами. А мы везде делаем проверки.

Вы правы. Скажу больше - недавно возникла интересная проблема. Мы доставали записи из MSSQL и клали в PG. Оказалось, что в некоторых строковвых полях в MSSQL были нулевые байты. И pg не мог их вставить, ругался на /u000 Когда мы сообщили DBA о том, что у нас такая проблема, их ответ был прост: "А вы добавьте NULLIF"

> И pg не мог их вставить, ругался на /u000 Э, подождите. PostgreSQL действительно не может хранить \x00 в text/varchar/char... как это Вы их оставили с нулевыми байтами?

> Когда мы сообщили DBA о том, что у нас такая проблема, их ответ был прост: "А вы добавьте NULLIF" Но это, да, "весело" (только что поверил своим глазам, что действительно это прочитал). ;)

> И pg не мог их вставить, ругался на /u000 Э, подождите. PostgreSQL действительно не может хранить \x00 в text/varchar/char... как это Вы их оставили с нулевыми байтами?

мы не оставили. Мы на этапе SELECT'а из MSSQL проверяли на нулевые байты, удаляли. А потом уже эти данные в JSON, без нулевых байт, отдавались на откуп PG и он их вставлял нормально

Это ад, у нас неконсистенси данные, и мы пишем костыли на SQL, чтобы решить проблему.. Такие дела

мы не оставили. Мы на этапе SELECT'а из MSSQL проверяли на нулевые байты, удаляли. А потом уже эти данные в JSON, без нулевых байт, отдавались на откуп PG и он их вставлял нормально

А, ясно. Тем не менее, возвращаясь к Вашему вопросу — поставьте 9.6.10 локально и проверьте, или посмотрите release notes. И если у Вас заработает, то кого-то можно будет ткнуть в это носом. ;)

у вас кстати неправильно время конвертится :-)

Вы правы. Скажу больше - недавно возникла интересная проблема. Мы доставали записи из MSSQL и клали в PG. Оказалось, что в некоторых строковвых полях в MSSQL были нулевые байты. И pg не мог их вставить, ругался на /u000 Когда мы сообщили DBA о том, что у нас такая проблема, их ответ был прост: "А вы добавьте NULLIF"

Это прикол от МС такой. Данные если выгружать через bcp, то null он заменяет нулевым байтом. Для загрузки в pg я писал скрипт, который преобразует хреновые данные от МС в кошерные для загрузки в pg

у вас кстати неправильно время конвертится :-)

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

Пардон, пустые строки, а не null

Это прикол от МС такой. Данные если выгружать через bcp, то null он заменяет нулевым байтом. Для загрузки в pg я писал скрипт, который преобразует хреновые данные от МС в кошерные для загрузки в pg

Если я не ошибаюсь, у нас были пустые строки в начале. '/u000 USA'

select to_timestamp('2018-09-05T00:00:00Z', 'YYYY-MM-DD HH24:MI:SS.MS'); to_timestamp ------------------------ 2018-09-05 00:00:00+03 (1 row) в msk это 3 часа ночи должно быть, а у вас полночь получается, потому что формат игнорирует зону 'Z'

вам везёт что у вас timezone сессии utc :-)