Обсуждение: Streaming Replication Postgresql 16

Hi,

Do the below processes look OK for a standby (streaming replication) server? We recently migrated from 12 to 16. I don't remember seeing "startup recovering"  process for a long time after starting of standby server on postgresql 12, it has been long time so I could be wrong.  Just want to make sure my standby is in a good shape. I have run some queries on standby to see if latest data is available and seems like it is there.

postgres   16909       1  0 May15 ?        00:00:00 /usr/lib/postgresql/16/bin/postgres -D /var/lib/postgresql/16/main -c config_file=/etc/postgresql/16/main/postgresql.conf
postgres   16910   16909  0 May15 ?        00:00:00 postgres: 16/main: logger
postgres   16911   16909  0 May15 ?        00:00:54 postgres: 16/main: checkpointer
postgres   16912   16909  0 May15 ?        00:00:03 postgres: 16/main: background writer
postgres   16913   16909  0 May15 ?        00:03:14 postgres: 16/main: startup recovering 0000000100000085000000E2
postgres   17012   16909  0 May15 ?        00:03:04 postgres: 16/main: walreceiver streaming 85/E24B6000

Also seeing log entries about every 5 minutes as shown below. These were not present when we were running 12.

2024-05-16 16:17:02.981 CDT: : 16911: LOG:  restartpoint starting: time
2024-05-16 16:18:58.337 CDT: : 16911: LOG:  restartpoint complete: wrote 1132 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=113.465 s, sync=1.688 s, total=115.356 s; sync files=155, longest=0.058 s, average=0.011 s; distance=21216 kB, estimate=174182 kB; lsn=85/FCFA8AA8, redo lsn=85/FCB6C578
2024-05-16 16:18:58.337 CDT: : 16911: LOG:  recovery restart point at 85/FCB6C578
2024-05-16 16:18:58.337 CDT: : 16911: DETAIL:  Last completed transaction was at log time 2024-05-16 16:18:57.612916-05.

Appreciate your help.

Thanks,
Prasanth

On Thu, 2024-05-16 at 16:27 -0500, Prasanth wrote:
> Do the below processes look OK for a standby (streaming replication) server? We recently migrated from 12 to 16. I
don'tremember seeing "startup recovering"  process for a long time after starting of standby server on postgresql 12,
ithas been long time so I could be wrong.  Just want to make sure my standby is in a good shape. I have run some
querieson standby to see if latest data is available and seems like it is there. 
>  
>
>  postgres   16909       1  0 May15 ?        00:00:00 /usr/lib/postgresql/16/bin/postgres -D
/var/lib/postgresql/16/main-c config_file=/etc/postgresql/16/main/postgresql.conf 
>  postgres   16910   16909  0 May15 ?        00:00:00 postgres: 16/main: logger
>  postgres   16911   16909  0 May15 ?        00:00:54 postgres: 16/main: checkpointer
>  postgres   16912   16909  0 May15 ?        00:00:03 postgres: 16/main: background writer
>  postgres   16913   16909  0 May15 ?        00:03:14 postgres: 16/main: startup recovering 0000000100000085000000E2
>  postgres   17012   16909  0 May15 ?        00:03:04 postgres: 16/main: walreceiver streaming 85/E24B6000
>  
>
>  Also seeing log entries about every 5 minutes as shown below. These were not present when we were running 12.
>  
>
>  2024-05-16 16:17:02.981 CDT: : 16911: LOG:  restartpoint starting: time
>  2024-05-16 16:18:58.337 CDT: : 16911: LOG:  restartpoint complete: wrote 1132 buffers (0.1%); 0 WAL file(s) added, 0
removed,0 recycled; write=113.465 s, sync=1.688 s, total=115.356 s; sync files=155, longest=0.058 s, average=0.011 s;
distance=21216kB, estimate=174182 kB; lsn=85/FCFA8AA8, redo lsn=85/FCB6C578 
>  2024-05-16 16:18:58.337 CDT: : 16911: LOG:  recovery restart point at 85/FCB6C578
>  2024-05-16 16:18:58.337 CDT: : 16911: DETAIL:  Last completed transaction was at log time 2024-05-16
16:18:57.612916-05.

That looks all hunky-dory.

The startup process has always been there, and so have been the restartpoints.
What might be new for you are the log messages, because "log_checkpoints" defaults to "on"
in PostgreSQL v16.  If the messages bother you, you can disable the parameter.
If the messages don't bother you, keep them.  They can be useful for debugging storage problems.

Yours,
Laurenz Albe