Betr: Re: FATAL: terminating connection due to administrator command

From: Alban Hertroys <alban(dot)hertroys(at)apollovredestein(dot)com>
To: "Srinivasa T N" <seenutn(at)gmail(dot)com>
Cc: "PostgreSQL General" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Betr: Re: FATAL: terminating connection due to administrator command
Date: 2020-10-01 12:18:42
Message-ID: OF29BEBFE9.F4E15BD2-ONC12585F4.0042F4DE-C12585F4.0043824E@apollotyres.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Srinivasa T N" <seenutn(at)gmail(dot)com> wrote on 01/10/2020 11:47:33:

> On Thu, Oct 1, 2020 at 2:47 PM Alban Hertroys <
> alban(dot)hertroys(at)apollovredestein(dot)com> wrote:
> Hi all,
>
> We're seeing the FATAL error message from the subject pop up in our
> logs at regular intervals, but I haven't been able to pinpoint what
> is causing it. I'm hoping for some insights here.
>
> We run a PostgreSQL 11.9 server on CentOS 7, within a vmware
environment:
> PostgreSQL 11.9 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
> 20150623 (Red Hat 4.8.5-39), 64-bit
>
> The package was installed from the PGDG repository.
>
> I'm not even sure I should be worried, there doesn't appear to be
> any impact on the servers' functioning, but it does say 'FATAL'.
> What we're seeing are lines like these two instances:
>
> 2020-09-30 22:27:56.446 CEST [30659] STATEMENT: select count(*)
> from "dm_b2b"."prlwytzkofskiv1"
> 2020-09-30 22:27:56.446 CEST [30658] FATAL: terminating
> connection due to administrator command
> 2020-09-30 22:27:56.446 CEST [30658] STATEMENT: select count(*)
> from "dm_b2b"."prlwytzkofskiv1"
> 2020-09-30 22:27:56.446 CEST [30657] FATAL: terminating
> connection due to administrator command
> 2020-09-30 22:27:56.446 CEST [30657] STATEMENT: select count(*)
> from "dm_b2b"."prlwytzkofskiv1"
> 2020-09-30 22:27:56.446 CEST [30656] FATAL: terminating
> connection due to administrator command
> 2020-09-30 22:27:56.446 CEST [30656] STATEMENT: select count(*)
> from "dm_b2b"."prlwytzkofskiv1"
> 2020-09-30 22:27:56.446 CEST [30655] FATAL: terminating
> connection due to administrator command
> 2020-09-30 22:27:56.446 CEST [30655] STATEMENT: select count(*)
> from "dm_b2b"."prlwytzkofskiv1"
> 2020-09-30 22:27:56.459 CEST [6482] LOG: background worker
> "parallel worker" (PID 30655) exited with exit code 1
> 2020-09-30 22:27:56.459 CEST [6482] LOG: background worker
> "parallel worker" (PID 30656) exited with exit code 1
> 2020-09-30 22:27:56.459 CEST [6482] LOG: background worker
> "parallel worker" (PID 30657) exited with exit code 1
> 2020-09-30 22:27:56.459 CEST [6482] LOG: background worker
> "parallel worker" (PID 30658) exited with exit code 1
> 2020-09-30 22:27:56.459 CEST [6482] LOG: background worker
> "parallel worker" (PID 30659) exited with exit code 1
> 2020-09-30 22:43:08.459 CEST [8055] 172.30.2.25 selfservice_prd
> ERROR: schema "somethingelse" does not exist at character 71

> I am guessing that 6 background workers are started, 1 worker had
> the result and hence killing the other 5 workers. Maybe, some more
> pg experts can comment. Anyway, explain of your query helps.

I think you may have the right of it:

QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=3065970.74..3065970.75 rows=1 width=8)
-> Gather (cost=3065970.21..3065970.72 rows=5 width=8)
Workers Planned: 5
-> Partial Aggregate (cost=3064970.21..3064970.22 rows=1
width=8)
-> Nested Loop Left Join (cost=2772.30..2743631.23
rows=128535594 width=0)
Join Filter: ((avl.xxxxxxxxxx)::text <> ''::text)
-> Parallel Hash Left Join (cost=2772.01..943286.00
rows=5574292 width=13)
Hash Cond: (avl.xxxxxxxxxxxxxxxxx =
(dc.xxxxxxxxxxxxx)::integer)
-> Parallel Seq Scan on xxxxxxxxxxxxxxxxxxxx
avl (cost=0.00..596772.71 rows=5574171 width=21)
-> Parallel Hash (cost=2262.01..2262.01
rows=40800 width=8)
-> Parallel Index Only Scan using
xxxxxxxxxxxxxxxxxxxxxxxxxxxx on xxxxxxxxxxxxxxxxxxxx dc (cost=0.42..2
-> Index Scan using ix_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
on xxxxxxxxxxxxxxxxxxx dm (cost=0.29..0.31 rows=1 width=19)
Index Cond: ((avl.xxxxxxxxxx)::text =
(xxxxxxxxxx)::text)
Filter: ((xxxxxxxxxx)::text <> ''::text)
(14 rows)

So, apparently these FATAL errors are just caused by parallel workers
being aborted because they're no longer needed. Good to know.

Regards,
Alban.

Alban Hertroys
D: +31 (0)53 4 888 888 | T: +31 (0)53 4888 888 | E: alban(dot)hertroys(at)apollovredestein(dot)com
Apollo Vredestein B.V.| Ir. E.L.C. Schiffstraat 370, 7547 RD Enschede, The
Netherlands
Chamber of Commerce number: 34223268




The information contained in this e-mail is intended solely for the use of the
individual or entity to whom it is addressed. If you are not the intended
recipient, you are hereby notified that any disclosure, copying, distribution
or action in relation to the contents of this information is strictly
prohibited and may be unlawful and request you to delete this message and any
attachments and advise the sender by return e-mail. The confidentiality of this
message is not warranted. Apollo Vredestein and its subsidiaries rule out any
and every liability resulting from this or any other electronic transmission



Please consider the environment before printing this e-mail

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sean Brown 2020-10-01 14:51:03 pg_upgrade issue upgrading 10 -> 13
Previous Message Srinivasa T N 2020-10-01 09:47:33 Re: FATAL: terminating connection due to administrator command