Yes we use SSL to connect to DB.
Looked into code related to st_changecount :
https://github.com/postgres/postgres/blob/659e53498c3c04e4f400323c02bef98fe8d13ec8/src/include/pgstat.h#L1015-L1044
https://github.com/postgres/postgres/blob/659e53498c3c04e4f400323c02bef98fe8d13ec8/src/include/pgstat.h#L1015-L1044
From comment seems like each backend should have its own copy of PgBackendStatus, it means st_changecount should be different for each process. If st_changecount was corrupted for 1/2 process, how can it impact newly created process. So could you please help to understand then how come if we run new query via new console (means new process) that also is getting stuck.
On Wed, May 8, 2019 at 11:12 AM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
neeraj kumar <neeru.cse@xxxxxxxxx> writes:
> Took some time to get stack trace as we didn't had root permission.
> Attaching stack trace of two process (out of many) stuck for same query
> below[1][2]
Hmm, the line numbers in your stack traces don't agree with either v10
or HEAD branches for me. But assuming that you've correctly identified
where it's stuck:
> Seems like call is unable to come out of this loop :
> https://github.com/postgres/postgres/blob/master/src/backend/postmaster/pgstat.c#L3361-L3400
the only really obvious theory is that some process left its
st_changecount odd, which would more or less have to imply that
something threw an error between pgstat_increment_changecount_before
and pgstat_increment_changecount_after. There's only one place
where that seems very plausible, namely pgstat_bestart, which is
doing a rather scary amount of stuff in between. Are you using
either SSL or GSS?
regards, tom lane
-------------------------------------
Thanks
Neeraj Kumar,
+1 (206) 427-7267
Thanks
Neeraj Kumar,
+1 (206) 427-7267
