Re: Writing WAL files

On Sat, Oct 10, 2020 at 3:41 AM Peter J. Holzer wrote: > On 2020-10-05 11:29:04 -0600, Michael Lewis wrote: > > > > I suggest that in PG12 you can monitor the > > "lag" of a standby server more directly by looking at columns > > write_lag, > > flush_lag, replay_lag

Re: Writing WAL files

On 2020-10-05 11:29:04 -0600, Michael Lewis wrote: > > I suggest that in PG12 you can monitor the > "lag" of a standby server more directly by looking at columns > write_lag, > flush_lag, replay_lag in the pg_stat_replication view.  > > > And are those things

Re: Writing WAL files

On Monday, October 5, 2020, Robert Inder wrote: > But the change Adrian Klaverd highlighted suggests that this is > deliberately no longer the case, > and I am left wondering what it does, in fact do/mean now. > “If no WAL has been written since the previous checkpoint, new checkpoints will be s

Re: Writing WAL files

On Mon, 5 Oct 2020 at 18:29, Michael Lewis wrote: > > If you setup a scripted process to update a single row with a timestamptz > on the source/primary every minute, then you have a very simple consistent > change and also a way to check on the replica what is current time vs > last_scripted_upda

Re: Writing WAL files

> I suggest that in PG12 you can monitor the >> "lag" of a standby server more directly by looking at columns write_lag, >> flush_lag, replay_lag in the pg_stat_replication view. > > > And are those things updated when there are no changes to the master > database? > If so, can anyone make the case

Re: Writing WAL files

On Sunday, October 4, 2020, Robert Inder wrote: > than shipping an empty file every few minutes? > The file is not empty. We’re talking 16 megabytes in a default setup... David J.

Re: Writing WAL files

On Sun, 4 Oct 2020 at 20:52, Alvaro Herrera wrote: > > This is on purpose; archiving WAL files that contain nothing is pure > wastage of good electrons. Seriously? Oh, holy > I suggest that in PG12 you can monitor the > "lag" of a standby server more directly by looking at columns write_

Re: Writing WAL files

Hello Robert On 2020-Oct-04, Robert Inder wrote: > One of the things I like about the old PGSQL 9 setup is that it generates > and ships a WAL file every few minutes, even if nothing has happened in the > database. > I find it re-assuring to be able to see WAL files arriving and being > processed

Re: Writing WAL files

On 10/4/20 10:30 AM, Robert Inder wrote: On Sun, 4 Oct 2020 at 18:01, Adrian Klaver > wrote: On 10/4/20 9:54 AM, Robert Inder wrote: > I am moving a database from PSQL 9 (!) on CentOS 6 to PSQL 12 on CentOS 7 It would help to know what the x

Re: Writing WAL files

On 10/4/20 10:30 AM, Robert Inder wrote: On Sun, 4 Oct 2020 at 18:01, Adrian Klaver > wrote: On 10/4/20 9:54 AM, Robert Inder wrote: > I am moving a database from PSQL 9 (!) on CentOS 6 to PSQL 12 on CentOS 7 It would help to know what the x

Re: Writing WAL files

On Sun, 4 Oct 2020 at 18:01, Adrian Klaver wrote: > On 10/4/20 9:54 AM, Robert Inder wrote: > > I am moving a database from PSQL 9 (!) on CentOS 6 to PSQL 12 on CentOS 7 > > It would help to know what the x in 9.x is? Before version 10 of > Postgres, the second number denoted a major version. >

Re: Writing WAL files

On 10/4/20 9:54 AM, Robert Inder wrote: I am moving a database from PSQL 9 (!) on CentOS 6 to PSQL 12 on CentOS 7 It would help to know what the x in 9.x is? Before version 10 of Postgres, the second number denoted a major version. I have a pair of servers -- one live, one standby. The liv

Writing WAL files

I am moving a database from PSQL 9 (!) on CentOS 6 to PSQL 12 on CentOS 7 I have a pair of servers -- one live, one standby. The live server defines an archive_command as "rsync" to shift WAL files to the standby server, The standby server uses "pg_standby" to monitor and process incoming WAL