Obsolete or dead serverconnections after reboot

Hello community,

actually I have a problem wit PG13 on Windows 10 (both x64), Postgres 
version is 13.0.2.21090 from EDB installer.

I have to develop a logical replication cluster, where sometimes there 
happens a shutdown of one host. Logical replication works nice, thank 
you for that.

My issue is, when I do a normal Windows shutdown, when there are 
connections open to this database server and later this host comes up 
again in statistics I find the old connections from before shutdown. 
They don't go away and keep staying there over reboots. Only a restart 
of the Windows service throws them away.

The problem is, that they block a place in der connections counter of 
the server and after a while I cant login any more, because the maximum 
user-connection count is exceeded.

Example:
select pid, datid, application_name, usename , client_addr from 
pg_stat_activity;
before reboot (one active psql session, left it open on server shutdown):

   pid  | datid  | application_name | usename  |              client_addr
-------+--------+------------------+----------+---------------------------------------
  13548 | 156501 | psql             | postgres | 192.168.2.49

after reboot (and newly started psql session):

   pid  | datid  | application_name | usename  |              client_addr
-------+--------+------------------+----------+---------------------------------------
  13548 | 156501 | psql             | postgres | 192.168.2.49
  13764 | 156501 | psql             | postgres | 192.168.2.49

As we can see at pid column, the old connection is still there, but I 
have only on psql session open.

After restarting the postgres service( and psql reconnect):

   pid  | datid | application_name | usename  |              client_addr
-------+-------+------------------+----------+---------------------------------------
  12132 | 91805 | psql             | postgres | 192.168.2.49

Everything is like expected: one psql-session, one row in the statistics

Is there a way to avoid this (without restarting the service after every 
reboot). Is this a bug or a normal behavior?

Thank you,
Wolfgang

-- 
May the source be with you