On Thu, May 31, 2018 at 9:19 AM, Ashu Pachauri wrote:
> There was too much noise in the pg_stat_activity output, so I did not post
> it. I'll collect the output again and post.
>
> But, when I checked in pg_stat_activity, PID 18317 is the session that's
> running the ALTER statement and it was sh
There was too much noise in the pg_stat_activity output, so I did not post
it. I'll collect the output again and post.
But, when I checked in pg_stat_activity, PID 18317 is the session that's
running the ALTER statement and it was showing up as "active". So, it's not
blocked by anything, but the f
Ashu,
please, provide full output of:
\x
select * from pg_stat_activity ;
What you posted on github is only providing a list of blocked backends.
If I read it correctly, then PID 18317 is the root cause of all the locks, but
it does not show up in the list, not being blocked by anything...
Thanks Fabio for the reply.
The queries are blocked in the sense that I can see them in
pg_stat_activity.
Please find the query and its output for correlating the blocked activity
with blocking query from pg_state_activity and pg_locks:
https://gist.github.com/ashu210890/c39cd7a38ce37f4baab2f58e1a
Hi Ashu,
when you say 'almost every query in our application starts getting blocked'...
'blocked' as in 'they are stuck and can be seen in pg_stat_activity'? (in this
case, please post the full content of pg_stat_activity)
or
'blocked' as in 'they are waiting in pgbouncer pool?
regards,
We have been using Postgres 9.5.12 behind PGBouncer and facing some weird
issues. Whenever we running long running DDL statements (e.g. 'add index
concurently' or 'Alter table alter column type'), after some time, we start
seeing that almost every query in our application starts getting blocked.
I
