> On Mar 29, 2019, at 6:58 AM, Michael Paquier <michael@xxxxxxxxxxx> wrote: > >> On Thu, Mar 28, 2019 at 09:53:16AM -0600, Rob Sargent wrote: >> This is pg10 so it's pg_wal. ls -ltr >> >> >> -rw-------. 1 postgres postgres 16777216 Mar 16 16:33 >> 0000000100000CEA000000B1 >> -rw-------. 1 postgres postgres 16777216 Mar 16 16:33 >> 0000000100000CEA000000B2 >> >> ... 217 more on through to ... >> >> -rw-------. 1 postgres postgres 16777216 Mar 16 17:01 >> 0000000100000CEA000000E8 >> -rw-------. 1 postgres postgres 16777216 Mar 16 17:01 >> 0000000100000CEA000000E9 >> -rw-------. 1 postgres postgres 16777216 Mar 28 09:46 >> 0000000100000CEA0000000E > > In Postgres 10 and older versions, the server keeps WAL segment for > the last completed segment, and the previous completed segment. So > even if a checkpoint is issued, the current WAL insert point is never > really going to be on the first segment in pg_wal. Isn't that the > origin of what you think is a problem? So, say, if you issue a > checkpoint again, don't you see 0000000100000CEA000000B1 going away? I had CEA000000015, generated today, as only entry since Mar 16. Issued checkpoint, soon had CEA0000016 and 15. Five minutes later I still hav 15 and 16 (and of course all 271 from Mar 16). > > In Postgres 11, WAL segments worth only one checkpoint are kept > around. > -- > Michael
