|
Объйсните почему так происходит
|
|||
---|---|---|---|
#18+
Приветствую форумчане! Есть PostgreSQL, выполняется несколько запросов: Begin Work Begin Work Rollback Work Возникнет ли при выполнении Commit Work ошибка? Я не понимаю почему бегины вложенные и ошибка будет полюбому, но как объяснить такое поведение? Думаю я так, ошибка будет т.к. есть незавершенная транзакция, но как она может быть незавершенной если постгри не поддерживает вложенные транзакции, как тогда это смоделировать? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2015, 23:49 |
|
Объйсните почему так происходит
|
|||
---|---|---|---|
#18+
gromoboyПриветствую форумчане! Есть PostgreSQL, выполняется несколько запросов: Begin Work Begin Work Rollback Work Возникнет ли при выполнении Commit Work ошибка? Я не понимаю почему бегины вложенные и ошибка будет полюбому, но как объяснить такое поведение? Думаю я так, ошибка будет т.к. есть незавершенная транзакция, но как она может быть незавершенной если постгри не поддерживает вложенные транзакции, как тогда это смоделировать? А протестировать за 1 секунду никак было нельзя? Ошибки не будет а произойдет mboguk=# begin; BEGIN mboguk=# begin; WARNING: there is already a transaction in progress BEGIN mboguk=# abort; ROLLBACK mboguk=# commit; WARNING: there is no transaction in progress COMMIT Второй begin будет проигнорирован с warning. А rollback откатит транзакцию самую начальную. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 00:27 |
|
Объйсните почему так происходит
|
|||
---|---|---|---|
#18+
Maxim Boguk gromoboyПриветствую форумчане! Есть PostgreSQL, выполняется несколько запросов: Begin Work Begin Work Rollback Work Возникнет ли при выполнении Commit Work ошибка? Я не понимаю почему бегины вложенные и ошибка будет полюбому, но как объяснить такое поведение? Думаю я так, ошибка будет т.к. есть незавершенная транзакция, но как она может быть незавершенной если постгри не поддерживает вложенные транзакции, как тогда это смоделировать? А протестировать за 1 секунду никак было нельзя? Ошибки не будет а произойдет mboguk=# begin; BEGIN mboguk=# begin; WARNING: there is already a transaction in progress BEGIN mboguk=# abort; ROLLBACK mboguk=# commit; WARNING: there is no transaction in progress COMMIT Второй begin будет проигнорирован с warning. А rollback откатит транзакцию самую начальную. -- Maxim Boguk www.postgresql-consulting.ru Извините, но чтоб темы не плодить. Проблема такая, по наследству досталась кем то написанная система, проблема сейчас в том, что Postgres пишет около 5Гб логов в сутки, абсолютно весь лог состоит из записей WARNING: there is already a transaction in progress 1. Если не вникать в работу приложения, можно ли как то настроить PG на игнор этого варнинга? 2. Если вникать и переделывать приложение, какой алгоритм поиска подобных косяков? Включил log_statement = all наверное стоит логику от увиденных запросов LOG: statement: BEGIN; WARNING: there is already a transaction in progress LOG: execute <unnamed>: SELECT ... , разматывать в приложении? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 15:47 |
|
Объйсните почему так происходит
|
|||
---|---|---|---|
#18+
kliff, 1)никак 2)да полный лог и разматывать в приложении -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 00:25 |
|
Объйсните почему так происходит
|
|||
---|---|---|---|
#18+
Maxim Boguk, спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2020, 16:32 |
|
Объйсните почему так происходит
|
|||
---|---|---|---|
#18+
Maxim Boguk, не могли бы еще подсказать. например вся система обвешана долгими транзакциями. Как я понял на каждый запрос от приложения ПГ запускает новый процесс в операционной системе, запрос выполняется и висит там долго в состоянии idle in transaction, ждет коммита. Остальные запросы ждут высвобождения процесса, что его занять. То есть блокировка даже не на уровне БД, а на уровне очереди процессов. Я почитал, но не очень то понял, если установить pgBouncer между базой и приложением, будет ли он оперативно высвобождать эти процессы, например селект в которых уже отдал результат? Как я понял из всяких статей, часто упоминается, что ПГ плохо работает, когда количество процессов переваливает за 100. У меня например 300-400 процессов, из них 20 в состоянии active, iner 100 в idle и iner 200 в idle in transaction. Возможно я вообще не так понял суть происходящего конечно ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 10:26 |
|
Объйсните почему так происходит
|
|||
---|---|---|---|
#18+
Active - postgres выполняет работу. Все норм, если не висит дольше положенного Вашего профиля нагрузки. idle in transaction - postgres не выполняет работу, транзакция не завершена. Тут могут быть разные причины: 1. забыли commit\rolback, 2. отправили данные в приложение, приложение что-то делает и потом опять должно обратиться к postgres причем в этой же транзакции. idle - postgres ни чего не делает, транзакция завершена, но соединение не разорвано. Если у Вас соединения идут с сервера приложений (возможно нескольких), которое в свою очередь использует пул соединений, то это нормально и даже правильно(что бы не устанавливать каждый раз новые соединения используются существующие). Если же каждое соединение это отдельный клиент, то это уже не очень хорошая ситуация (клиент соединился, поработал, не разорвал соединение, ушел пить чай или вообще домой) при которой начинается борьба за ресурсы(соединения). Тут и надо задуматься по поводу промежуточного звена в виде пула соединений(PgBouncer|PgPool|что-то еще). Про pgpool не скажу, но у PgBouncer есть несколько режимов работы(соединений) в них стоит разобраться. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 11:01 |
|
Объйсните почему так происходит
|
|||
---|---|---|---|
#18+
kliff, pgbouncer от idle in transaction не поможет он помогает для расшаривания сотен-тысяч idle соединений на 1-10 реальных коннектов к базе а вот idle in transaction это уже соединение с базой занято до окончания транзакции. Так что pgbouncer вам поможет только убрать те 100 что в idle. idle in transaction всегда проблема приложения и там ее и надо лечить путем анализа почему оно возникает. В 99% случаев оно возникает когда приложение внутри транзакции начинает к каким то тормозящим внешним ресурсам обращаться что является очень плохой практикой. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 11:19 |
|
|
start [/forum/topic.php?fid=53&fpage=19&tid=1994329]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
15ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 296ms |
total: | 462ms |
0 / 0 |