SS
но пишет вот что
psycopg2.OperationalError: fe_sendauth: no password suppliedpsycopg2.OperationalError: fe_sendauth: no password suppliedSize: a a a
2021 February 01
AD
но пишет вот что
Коннектор не видит пароль. Точно в словаре не ошиблись в названии ключа?
ГА
Приветствую!
timescaledb continuous aggregates дружит ли с join?
Т.е. при создании cagg запрос join-ит hyper-таблицу с обычной и я получаю ошибку:
ERROR: only 1 hypertable is permitted in SELECT query for continuous aggregate
Ошибка относиться к запрету использования более одной hyper-таблицы в теле cagg.
Но я не нашел прямого упоминания запрета на join с обычной таблицей в теле cagg.
timescaledb continuous aggregates дружит ли с join?
Т.е. при создании cagg запрос join-ит hyper-таблицу с обычной и я получаю ошибку:
ERROR: only 1 hypertable is permitted in SELECT query for continuous aggregate
Ошибка относиться к запрету использования более одной hyper-таблицы в теле cagg.
Но я не нашел прямого упоминания запрета на join с обычной таблицей в теле cagg.
AD
но пишет вот что
psycopg2.OperationalError: fe_sendauth: no password suppliedА, у вас нет пароля, я понял.
Посмотрите вот это: https://stackoverflow.com/questions/11192134/connect-to-a-db-using-psycopg2-without-password
Посмотрите вот это: https://stackoverflow.com/questions/11192134/connect-to-a-db-using-psycopg2-without-password
SS
А, у вас нет пароля, я понял.
Посмотрите вот это: https://stackoverflow.com/questions/11192134/connect-to-a-db-using-psycopg2-without-password
Посмотрите вот это: https://stackoverflow.com/questions/11192134/connect-to-a-db-using-psycopg2-without-password
Спасибо. Решил проблему!
IK
Добрый день. Направьте, пожалуйста, на путь истинный. Есть запрос, среднее время выполнение которого 200мс. Но переодически его время выполнения вырастает в разы. До 120 секунд. Никаких локов, блокирующих трансзакцию не видно, в pg_stat_activity запрос в статусе active, никаких wait_event'ов не наблюдается.
IK
руками не могу воспроизвести проблему - всегда запрос отрабатывает в рамках нормы
IK
в каком направлении нужно копать, подскажите, пожалуйста
YS
Добрый день. Направьте, пожалуйста, на путь истинный. Есть запрос, среднее время выполнение которого 200мс. Но переодически его время выполнения вырастает в разы. До 120 секунд. Никаких локов, блокирующих трансзакцию не видно, в pg_stat_activity запрос в статусе active, никаких wait_event'ов не наблюдается.
В логах "поймайте" план (с помощью auto_explain), например.
IK
спасибо, попробую
YS
в каком направлении нужно копать, подскажите, пожалуйста
И, кстати, то, что Вы видите в pg_stat_activity — всего лишь "моментальный снимок".
Т.е. из 120 секунд он мог висеть на locks хоть 119, но Вам "повезло" попасть в ту секунду, когда их не было. ;)
Ещё вариант — попробовать pg_stat_statements.
Т.е. из 120 секунд он мог висеть на locks хоть 119, но Вам "повезло" попасть в ту секунду, когда их не было. ;)
Ещё вариант — попробовать pg_stat_statements.
IK
да, я предполагал, что мог удачно попасть на статус актив
IK
хотя старался делать запросы в pg_stat_activity чаще, в надежде "поймать" проблему
IK
в целом, ауто_эксплйен хорошая идея
AL
Yaroslav Schekin
И, кстати, то, что Вы видите в pg_stat_activity — всего лишь "моментальный снимок".
Т.е. из 120 секунд он мог висеть на locks хоть 119, но Вам "повезло" попасть в ту секунду, когда их не было. ;)
Ещё вариант — попробовать pg_stat_statements.
Т.е. из 120 секунд он мог висеть на locks хоть 119, но Вам "повезло" попасть в ту секунду, когда их не было. ;)
Ещё вариант — попробовать pg_stat_statements.
а бы даже добавил в тот короткий момент секунды )))
b
Только вот это вот сообщение при запуске:
Далее:
Интересно, не опасно ли отключить
database system was shut down in recovery at 2021-02-01 05:49:03 GMTДалее:
could not restore file "00000002.history" from archive: command not foundИнтересно, не опасно ли отключить
archive_mode в конфиге и попробовать запустить снова?Хмм, уже четвертый час запускается, последние слова в логе
redo starts at C99F/C52CC330, а на каждую попытку коннекта говорит the database system is starting upb
У реплики вот этот конфиг был, как видите,
Теперь только пересобирать реплику с нуля? 🥺
archive_command ничего не делала тк в какой-то момент ее заменили на пустую операцию.archive_mode = 'on'
archive_command = 'true'
restore_command = 's3cmd get "s3://core0-wal-dfjeff/core0/%f" "%p"'Теперь только пересобирать реплику с нуля? 🥺
Мне теперь нужно перезапустить мастер, на котором такой же конфиг:
archive_mode = `on`, но archive_command была заменена на true давным-давно. Как можно сервер остановить нежнейшим образом так, что рековери не заняла так же 4 часа?EK
Добрый день. Как понять насколько эффективно используется connection pool чтобы понять по сколько соединений на аппликейшен реально выдавать? Кроме как опытным путем.
РЖ
180-200 соединений с базой - оптимально.
Это для записи. Чистое чтение масштабируется гораздо лучше.
Это для записи. Чистое чтение масштабируется гораздо лучше.
V
больше 100 соединений деградация производительности идет