Betr: Re: FATAL: terminating connection due to administrator command - Mailing list pgsql-general
"Srinivasa T N" <seenutn@gmail.com> wrote on 01/10/2020 11:47:33:
> On Thu, Oct 1, 2020 at 2:47 PM Alban Hertroys <
> alban.hertroys@apollovredestein.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.hertroys@apollovredestein.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
> On Thu, Oct 1, 2020 at 2:47 PM Alban Hertroys <
> alban.hertroys@apollovredestein.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.hertroys@apollovredestein.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 | ||
Attachment
pgsql-general by date: