I had this misfortune to support a Dev DB on 9.3 PostgreSQL running on Win server 2008 R2 which I had the joy of taking from 9.3 to 9.4, 9.5 and 9.6 in fits and starts. Thankfully Production ran on Debian Linux which would upgrade faultlessly This looks like it might be a file ownership issue, was PostgreSQL installed under an account called Postgres or the network service account? Which account owns the Postgres files and which account is running the Postgres Service process? Is the ownership/ acls of the WAL files correct or matching and are they being deleted correctly? As I recall Postgres 9.3 expected the install to be made using a non-privileged Postgres account whereas this changed in later versions to expecting the network service account to be used instead. Hope this helps, Peter G. On 25/04/2020 at 6:13 PM, "Luis Marin" <luismarinaray@xxxxxxxxx> wrote: > >Dear PostgreSQL friends: > >I have a terrible task. > >Build a replication schema using a Windows Server2016 and >PostgreSQL 9.3. > >I know, I know , I could have desired, a better or most recent >PostgreSQL >version, but nope > >My current configuration: > >Master Server: >postgresql.conf: > >wal_level = hot_standby > >archive_mode = on > >archive_command = 'copy "%p" "\\\\127.0.0.1\\archive\\%f"' > >max_wal_senders = 5 >wal_keep_segments = 10 > >pg_hba.conf: > >host replication rep_user IP-replica slave/CIDR > trust > > >Slave Server: > > >postgresql.conf: > >Hot_Standby=On > > >recovery.conf > >restore_command = 'copy "\\\\x.y.z.78\\Archive\\%f" "%p"' > >standby_mode = 'on' > >primary_conninfo= 'host=x.y.z.78 port=5432 user=rep_user >password=rep_user' > >trigger_file = 'c:\\temp\\primary_down.txt' > >I have made a successfully switch-over, but my new slave server, >does not >want to be online >I have enabled more detailed debug info, and the only message that >appears >is: > >2020-04-25 11:49:36 COT DEBUG: attempting to remove WAL segments >older >than log file 00000000000000000000004A >2020-04-25 11:49:36 COT DEBUG: SlruScanDirectory invoking >callback on >pg_multixact/offsets/0000 >2020-04-25 11:49:36 COT DEBUG: SlruScanDirectory invoking >callback on >pg_multixact/members/0000 >2020-04-25 11:49:36 COT DEBUG: SlruScanDirectory invoking >callback on >pg_multixact/offsets/0000 > >My log file keeps growing, but the postgresql service fails to >start with a >timeout message and never comes online. >what could be happening ? > >Please, any idea, can help me >Thanks a lot friends for your postgresql-wise > >Best Regards
