KK
Size: a a a
2020 June 15
IK
как вариант можно прописать 'German,DMY'
Так не работает, не хочет вместе и German, и DMY
А только German не хочет, потому что для jdbc нужен ISO
А только German не хочет, потому что для jdbc нужен ISO
YS
У меня не просто выборка, у меня миграция, которую запускаю на той же машине, где и база (На ноуте)
Да проверьте Вы эту установку внимательно.
Может, сама эта "миграция" делает SET datestyle = '...';
Может, сама эта "миграция" делает SET datestyle = '...';
YS
Поставил ISO, DMY, не помогло
Т.е. у меня всё работает. :)
IK
Yaroslav Schekin
Да проверьте Вы эту установку внимательно.
Может, сама эта "миграция" делает SET datestyle = '...';
Может, сама эта "миграция" делает SET datestyle = '...';
Проверил, не делает
YS
Проверил, не делает
Ладно, а если по шагам:
. Где Вы меняете datestyle?
. И где / как тестируете?
. Где Вы меняете datestyle?
. И где / как тестируете?
IK
Yaroslav Schekin
Ладно, а если по шагам:
. Где Вы меняете datestyle?
. И где / как тестируете?
. Где Вы меняете datestyle?
. И где / как тестируете?
Меняю в бд через SET
Тестирую через запуск миграций через flyway, либо можно взять ту же миграцию и запустить руками в условном дбивере
DATESTYLE TO 'ISO,DMY'Тестирую через запуск миграций через flyway, либо можно взять ту же миграцию и запустить руками в условном дбивере
IK
Ошибки одинаковые -
Message : ERROR: date/time field value out of range: "31.12.2019"
Hint: Perhaps you need a different "datestyle" setting.
YS
Меняю в бд через SET
Тестирую через запуск миграций через flyway, либо можно взять ту же миграцию и запустить руками в условном дбивере
DATESTYLE TO 'ISO,DMY'Тестирую через запуск миграций через flyway, либо можно взять ту же миграцию и запустить руками в условном дбивере
Подробнее! "SET
DATESTYLE TO 'ISO,DMY'" ничего не меняет "в БД" — это меняет текущую настройку только в Вашей сессии.IK
Yaroslav Schekin
Подробнее! "SET
DATESTYLE TO 'ISO,DMY'" ничего не меняет "в БД" — это меняет текущую настройку только в Вашей сессии.Ах вот оно как
IK
А глобально можно как-то?
YS
А глобально можно как-то?
postgresql.conf, ALTER SYSTEM, ALTER DATABASE или ALTER ROLE — как хотите. ;)
После изменения первых двух нужно выполнить
А последние подействуют при подключении новой сессии.
После изменения первых двух нужно выполнить
SELECT pg_reload_conf();
А последние подействуют при подключении новой сессии.
IK
Yaroslav Schekin
postgresql.conf, ALTER SYSTEM, ALTER DATABASE или ALTER ROLE — как хотите. ;)
После изменения первых двух нужно выполнить
А последние подействуют при подключении новой сессии.
После изменения первых двух нужно выполнить
SELECT pg_reload_conf();
А последние подействуют при подключении новой сессии.
Спасибо, сейчас попробую
IK
Yaroslav Schekin
postgresql.conf, ALTER SYSTEM, ALTER DATABASE или ALTER ROLE — как хотите. ;)
После изменения первых двух нужно выполнить
А последние подействуют при подключении новой сессии.
После изменения первых двух нужно выполнить
SELECT pg_reload_conf();
А последние подействуют при подключении новой сессии.
Офигеть, ALTER SYSTEM помогло!
IK
Огромное спасибо!
YS
Огромное спасибо!
Да не за что! ;)
D
Yaroslav Schekin
> Подсказали, что можно стопнуть реплику (мастер один нагрузку легко тянет), включить там чексуммы
Кто подсказал-то (такое я тоже слышал, и с виду оно может и работать, но не делал)? ;)
Я к чему — может, у них спросить, как прошло / были ли проблемы?
Далее:
1. Стопнуть реплику (мастер один нагрузку легко тянет), включить там чексуммы
2. Сделать свитчовер
Вот где-то перед этим шагом реплика, по идее, должна быть "докачена" WAL-ами с primary, нет?
3. включить чексуммы на другом сервере,
4. сделать свитчовер ещё раз
И перед этим — тоже, см. выше.
> реплика мастером стала, а вот прежний мастер к ней подцепить репликой не удалось
timelines разошлись, наверное. Тогда же pg_rewind ещё не было, вроде?
> Сейчас, если свитчовер также не удастся, нам придётся дважды тянуть полтора терабайта по сети
Не обязательно. Как раз тут можно подумать, как правильно применить pg_rewind, по идее.
> где соломки подстелить.
А Вы на "урезанных" тестовых кластерах (к примеру, с теми же схемами и почти без данных; или вообще на тестовых базах) потренируйтесь. :)
> где упоминается ещё "убедиться что валы догнались" (как?)
См. https://www.postgresql.org/docs/current/app-pgcontroldata.html , по идее.
> и настройка recovery.conf (которого у нас нет)
Это потому, что у Вас v12.
> Или надо что-то ещё проверить / не забыть / и т.п?
Почитали бы Вы официальную документацию, для начала. ;)
Кто подсказал-то (такое я тоже слышал, и с виду оно может и работать, но не делал)? ;)
Я к чему — может, у них спросить, как прошло / были ли проблемы?
Далее:
1. Стопнуть реплику (мастер один нагрузку легко тянет), включить там чексуммы
2. Сделать свитчовер
Вот где-то перед этим шагом реплика, по идее, должна быть "докачена" WAL-ами с primary, нет?
3. включить чексуммы на другом сервере,
4. сделать свитчовер ещё раз
И перед этим — тоже, см. выше.
> реплика мастером стала, а вот прежний мастер к ней подцепить репликой не удалось
timelines разошлись, наверное. Тогда же pg_rewind ещё не было, вроде?
> Сейчас, если свитчовер также не удастся, нам придётся дважды тянуть полтора терабайта по сети
Не обязательно. Как раз тут можно подумать, как правильно применить pg_rewind, по идее.
> где соломки подстелить.
А Вы на "урезанных" тестовых кластерах (к примеру, с теми же схемами и почти без данных; или вообще на тестовых базах) потренируйтесь. :)
> где упоминается ещё "убедиться что валы догнались" (как?)
См. https://www.postgresql.org/docs/current/app-pgcontroldata.html , по идее.
> и настройка recovery.conf (которого у нас нет)
Это потому, что у Вас v12.
> Или надо что-то ещё проверить / не забыть / и т.п?
Почитали бы Вы официальную документацию, для начала. ;)
@gsmolk в этом чате и подсказал :)
pg_rewind нельзя использовать, так в доке pg_checksum написано - чексуммы меняют файлы на диске
в целом должно сработать, понял, спасибо)
pg_rewind нельзя использовать, так в доке pg_checksum написано - чексуммы меняют файлы на диске
в целом должно сработать, понял, спасибо)
TS
Yaroslav Schekin
Да не за что! ;)
Добрый вечер!
Как большой знаток работы планировщика, не подскажете ли вот что?
В конструкции
CASE
WHEN field IS NOT NULL THEN field
ELSE SELECT value FROM table
END as data,
конструкция будет выполняться ленивым образом или нет? И если да, то где это написано? То есть есть ли гарантия на уровне стандарта?
Заранее спасибо.
Как большой знаток работы планировщика, не подскажете ли вот что?
В конструкции
CASE
WHEN field IS NOT NULL THEN field
ELSE SELECT value FROM table
END as data,
конструкция будет выполняться ленивым образом или нет? И если да, то где это написано? То есть есть ли гарантия на уровне стандарта?
Заранее спасибо.
YS
@gsmolk в этом чате и подсказал :)
pg_rewind нельзя использовать, так в доке pg_checksum написано - чексуммы меняют файлы на диске
в целом должно сработать, понял, спасибо)
pg_rewind нельзя использовать, так в доке pg_checksum написано - чексуммы меняют файлы на диске
в целом должно сработать, понял, спасибо)
Вот у него и надо спрашивать, как оно на практике. ;)
> pg_rewind нельзя использовать, так в доке pg_checksum написано - чексуммы меняют файлы на диске
Я имел в виду — для отката на каких-то этапах, если что. Как pg_rewind узнает, что файлы кто-то менял? ;)
> pg_rewind нельзя использовать, так в доке pg_checksum написано - чексуммы меняют файлы на диске
Я имел в виду — для отката на каких-то этапах, если что. Как pg_rewind узнает, что файлы кто-то менял? ;)
YS
Добрый вечер!
Как большой знаток работы планировщика, не подскажете ли вот что?
В конструкции
CASE
WHEN field IS NOT NULL THEN field
ELSE SELECT value FROM table
END as data,
конструкция будет выполняться ленивым образом или нет? И если да, то где это написано? То есть есть ли гарантия на уровне стандарта?
Заранее спасибо.
Как большой знаток работы планировщика, не подскажете ли вот что?
В конструкции
CASE
WHEN field IS NOT NULL THEN field
ELSE SELECT value FROM table
END as data,
конструкция будет выполняться ленивым образом или нет? И если да, то где это написано? То есть есть ли гарантия на уровне стандарта?
Заранее спасибо.
Что такое "ленивым", в данной ситуации? ;)
В смысле, будет ли выполняться ELSE, если это не нужно?
Это зависит от того, что там — в случае constant folding и т.п. — будет, иначе executor будет выполнять ELSE только когда нужно, по идее (не уверен, что во всех случаях, конечно).
> И если да, то где это написано?
Т.е. на практике — чаще всего, выполняться не будет. Написано это здесь:
https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-CASE
> То есть есть ли гарантия на уровне стандарта?
Но нет, гарантии как в PostgreSQL (см. https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-EXPRESS-EVAL ), так и в ISO SQL (насколько я понял — могу ошибаться, конечно) нет.
А в общем, в этом отношении postgres (как и многие другие СУБД, говорят) старается, чтобы это как можно чаще работало, потому что многие программисты этого (по каким-то причинам ;) ) ожидают. Но не всегда получается, как видите.
В смысле, будет ли выполняться ELSE, если это не нужно?
Это зависит от того, что там — в случае constant folding и т.п. — будет, иначе executor будет выполнять ELSE только когда нужно, по идее (не уверен, что во всех случаях, конечно).
> И если да, то где это написано?
Т.е. на практике — чаще всего, выполняться не будет. Написано это здесь:
https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-CASE
> То есть есть ли гарантия на уровне стандарта?
Но нет, гарантии как в PostgreSQL (см. https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-EXPRESS-EVAL ), так и в ISO SQL (насколько я понял — могу ошибаться, конечно) нет.
А в общем, в этом отношении postgres (как и многие другие СУБД, говорят) старается, чтобы это как можно чаще работало, потому что многие программисты этого (по каким-то причинам ;) ) ожидают. Но не всегда получается, как видите.