ane wrote:
> neeraj kumar writes:
> > Also curious why query on pg_stat_activity is considering terminated
> > process ?
>
> The short answer to that is that this bug leaves shared memory in
> a corrupt state. It's not really useful to worry about whether
> reade
Also curious why query on pg_stat_activity is considering terminated
process ? Irrespective of corrupted state or not, ideally query on
pg_stat_activity
should ignore already terminated process.
My 2 cents.
On Fri, May 10, 2019 at 8:01 AM neeraj kumar wrote:
> There are multiple ways see t
May 9, 2019 at 9:29 PM Tom Lane wrote:
> neeraj kumar writes:
> > Tom, may be I didn't make my point clear.
> > There are two issues :
> > 1) Why this value was left as odd
>
> Because a function called by pgstat_bestart threw an error, is what
> I'm
he same mistake again, at least there'll be a pretty obvious
> failure rather than a lot of stuck readers.
>
> regards, tom lane
>
--
-
Thanks
Neeraj Kumar,
+1 (206) 427-7267
roken?
Ideally this issue should have stayed till this process was active. If
entry from beentry would have been removed after process was killed, system
should have auto recovered.
On Thu, May 9, 2019 at 8:25 PM Tom Lane wrote:
> neeraj kumar writes:
> > We got more information ab
:12 AM Tom Lane wrote:
> neeraj kumar 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 do
x14ed51dfa380) at postmaster.c:4458
#23 ServerLoop () at postmaster.c:1930
#24 0x00739d58 in PostmasterMain (argc=argc@entry=9,
argv=argv@entry=0x14ed51c246f0)
at postmaster.c:1557
#25 0x004d1594 in main (argc=9, argv=0x14ed51c246f0) at main.c:228
[14:53:43][root][~]$
On Mon, M
