BUG #16039: PANIC when activating replication slots in Postgres 12.0 64bit under Windows

The following bug has been logged on the website:

Bug reference: 16039
Logged by: Hans Buschmann
Email address: buschmann(at)nidsa(dot)net
PostgreSQL version: 12.0
Operating system: Windows Server 2019 64bit
Description:

We just moved our production cluster from pg 11.5 to pg 12.0 under windows
using pg_dump/initdb/pg_restore.

When we activated the replication slots by

SELECT * FROM pg_create_physical_replication_slot('sam_repli_3');

and tried restarting the server, we got a PANIC in error log:

CPS PRD 2019-10-04 19:10:07 CEST 00000 1:> LOG: database system was shut
down at 2019-10-04 19:10:02 CEST
CPS PRD 2019-10-04 19:10:07 CEST XX000 2:> PANIC: could not fsync file
"pg_replslot/sam_repli_3/state": Bad file descriptor
CPS PRD 2019-10-04 19:10:07 CEST 00000 6:> LOG: startup process (PID
4028) was terminated by exception 0xC0000409
CPS PRD 2019-10-04 19:10:07 CEST 00000 7:> HINT: See C include file
"ntstatus.h" for a description of the hexadecimal value.
CPS PRD 2019-10-04 19:10:07 CEST 00000 8:> LOG: aborting startup due to
startup process failure
CPS PRD 2019-10-04 19:10:07 CEST 00000 9:> LOG: database system is shut
down

We use the EDB distribution from the website under Windows Server 2019
(September 2019 patch level).

select version ();
version
------------------------------------------------------------
PostgreSQL 12.0, compiled by Visual C++ build 1914, 64-bit
(1 Zeile)

This seems to me like a fatal bug which makes the streaming replication
unusable under Windows x64 /pg12.

The same configuration worked flawlessly under pg 11.x until pg 11.5

By searching on google we encountered a similar error from 2015 under pg
9.4.1 reported under BUG #13287:

https://www.postgresql.org/message-id/flat/20150514105514.2691.67352%40wrigleys.postgresql.org

We were able to remove the replication slot by deleting the directory
pg_replslot/sam_repli_3.

The server seems to be working fine now, but without streaming replication
of course.

BTW: Is it necessary to restart the cluster after creating the replication
slot or is it a consequence of the error, that the
newly created slot is not active automatically?

select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active |
active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
-------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------
sam_repli_3 | | physical | | | f | f |
| | | |
sam_repli_5 | | physical | | | f | f |
| | | |
(2 Zeilen)

Many thanks!

Hans Buschmann