exectime=0.005206
rows=0
SELECT room_id, type, count(CASE WHEN not upperplace THEN 1 END) AS amount, count(CASE WHEN upperplace THEN 1 END) AS up_amount FROM u5.t5_room_occupied WHERE '2019-06-17T08:00:00'::timestamp <= dep_date AND entry_date <= '2019-06-20T09:00:00'::timestamp AND apartment_id=35 AND NOT (tour_id <> 8296 AND tour_lock) GROUP BY room_id, type
Хотя, признаться, не понимаю, что это может вам дать...
rPman, железо в порядке. Да и сервер - это VDS на хостинге провайдера, там и без меня следят за этим. Если бы был сбой, который потом провайдер оперативно поправил, тогда бы в логах остались следы. Их нет. Мистика, короче...
Проверял код между запросом и ответом от базы данных, ничего подозрительного.
> Я бы добавил отладочную информацию прямо в код...
Система пишет расширенный лог постоянно, это её нормальное состояние, и в этом логе и дата, и текст запроса "как есть", и количество записей в ответе. Именно это и помогло выполнить анализ происходящего, впрочем, безуспешно.
БД и приложение на одном сервере, сетевой ошибки не должно быть.
С файловой системой и БД всё в порядке, утилиты отработали без ошибок. В логах тоже ничего подозрительного.
Уже весь мозг вывихнул. И ещё нюанс: на самом деле приложение выполняет два запроса с перерывом в несколько минут. Первый запрос проверяет наличие этих записей, и если их нет - позволяет юзеру выполнить некоторые действия. Второй запрос - контрольный, и он внешне отличается от первого, но по сути также проверяет наличие этих записей (вдруг их кто-то добавил, пока юзер копался на сайте). Перед вторым запросом выполняется блокировка таблиц. И вот обе эти проверки не сработали, будто на несколько минут эти записи стали невидимыми.
Это работает уже много лет, никогда ничего подобного не происходило, поэтому я не склонен думать, что это архитектурная ошибка приложения. Но в то же время я не представляю, как такое в принципе возможно в postgresql.
Melkij, select version:
PostgreSQL 9.5.14 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609, 64-bit
Я не очень глубокий знаток postgresql, поэтому не буду спорить по поводу наличия кэша запросов. Если верить информации из соотв. форумов, то postgres кэширует только данные и индексы. Но что бы он там не кэшировал, я не могу связать случившееся с работой кэша, у меня в голове цепочка не укладывается. Хотелось бы услышать от специалистов конкретный сценарий: что (по шагам) могло привести к такому поведению системы?
Vitsliputsli, согласен с вами, но проблема в том, что я не могу воспроизвести эту ситуацию с отключенным кэшем, т.к. а) ситуация была на боевом сервере, где собственно кэш, а я тестирую на dev, и б) ситуация была в прошлом, т.е. 2 недели назад. Сейчас всё что есть - это архив БД на момент инцидента. И потом, я не вижу, как именно кэш мог повлиять на ответ. Если бы запрос вернул строки из кэша, а их реально в таблице уже не было - это понятно, можно грешить на кэш. Но запрос не вернул записей. И тогда у меня возникает вопрос: а в принципе мог кэш ответить, что записей нет, хотя они там были?
Да и кеширование не очень хочется отключать. Такое произошло впервые за много лет, и неизвестно, произойдёт ли ещё раз. Но хочется понять причину.
Vitsliputsli, а что именно копать? Да и дело в том, что записи, которые должны были быть возвращены, находились там без изменений с апреля 2018 года, т.е. уже год. Значит, и в кэше, если он "застарел", они тоже должны были быть. Так что вряд ли эта проблема в кэше.
Обычно фронтендеры не правят css напрямую. Для того и создан scss, чтобы делать это более эффективно и наглядно.
Для компиляции используют разнообразные watcher-ы, выбирайте на свой вкус. Если в IDE, которую вы используете, нет встроенного компилятора scss (как например в PyCharm), можете использовать подход, описанный в maxsite.org/page/sass-to-css
