Всем привет. Есть приложение на .net которое пишет в бд

данные. Иногда в таблицах проскакивает BC даты (до нашей эры). Приложение на .net не могло передать такую дату, так как тип отвечающий за дату не переваривает значения выходящие за пределы 0001-9999 по годам. Это какая то бага постгри. Сталкивался кто с таким?

> Приложение на .net не могло передать такую дату, так как тип отвечающий за дату не переваривает значения выходящие за пределы 0001-9999 по годам. Non sequitur. То, что в .net преобразовывает этот тип для передачи, могло "сломать" значение, например. > Это какая то бага постгри. Т.е. совсем не факт. А Вы можете воспроизвести? Или залогировать запросы этого приложения (включить для них логирование в PostgreSQL, я имею в виду)? И вообще, в логах PostgreSQL есть что-то "странное" (вдруг эта база вообще "битая")?

> Non sequitur. То, что в .net преобразовывает этот тип для передачи, могло "сломать" значение, например. Есть цепочка. Источник данных -> .NET -> PGS. Если источник передает в .NET дату в нашей эре, т.е. от 0001-01-01, то .NET ее примет и запишет в БД. Если источник передаст дату до нашей эры, то .NET отвалится уже на этом этапе и до процесса записи в БД дело не дойдет. Соответственно вывод. Источник и .NET обработали нашу эру, .NET записал данные в таблицу, постгря сломала даты. Так как даты "сломаны" .net не может обратно их прочитаться из БД. Причем заметил (сейчас сломанные даты затерты для работы приложения), что сломанным датам не хватает 29 минут до "нашей эры". Т.е. значение "0001-01-01 23:31 BC" или около того

Хмм... мне ещё раз написать то же самое? ;( Хорошо, Ваш вывод не следует из посылок, и я показал Вам пример одного из мест, где оно может "ломаться". > .NET записал данные в таблицу, Вот это место, ещё раз. В общем, почему бы Вам не включить логирование запросов? Так будет точно понятно, "кто виноват", хотя бы.

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

А это хоть настоящий PostgreSQL, или какая-то хорошая (если верить vendor-у) имитация? ;) Я к тому, что если второе — это вообще не сюда... А что значит "прямого доступа нет"? Ни у кого нет прав superuser в этом instance PostgreSQL (права в OS на сервере, где он установлен, не нужны)?

Вроде настоящий. Логи включаются через запрос? А прочитать их можно без проникновения в FS сервера? Если да, то трудностей не составит все это включить и смотреть.

> Логи включаются через запрос? Можно и через запрос, да. ALTER SYSTEM / ALTER ROLE / ALTER DATABASE (что удобнее / точнее) + reload. > А прочитать их можно без проникновения в FS сервера? Superuser-у можно, конечно... но неудобно / это hacks. См. https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE Ну или COPY FROM | "PROGRAM". Поэтому куда удобнее, если доступ под postgres всё же есть.

Во, вместо записи 0001-01-01 вставляет такую дату 0001-12-31 21:29:43.000 BC При чем во всех случаях

Т.е. Вы до логов добрались, всё-таки? Можете запрос оттуда показать?

Да. Сейчас скину

Dmitriy Gavrilenko

Во-первых, откуда этот лог (как-то он на логи PostgreSQL не похож)? Во-вторых, какого типа поле modified (и что выводит запрос к этой записи в psql)?

Это логи из postgresql, просто облачный провайдер отображает их таким вот образом modified timestamp(3) with time zone not null значение - 0001-12-31 21:29:43.000 BC

> значение - 0001-12-31 21:29:43.000 BC psql на запрос к полю такого типа такогой дряни не выдаст никогда. Вы думаете, я просто так обратил внимание, что результат нужен из него?

Сейчас пришлю пруф