On Tue, Jun 23, 2020 at 10:10:37AM +0900, Kyotaro Horiguchi wrote: > At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao <masao.fu...@oss.nttdata.com> > wrote in >> Isn't this confusing? I think that we should store the last removed >> WAL segment to somewhere (e.g., pg_control) and restore it at >> the startup, so that we can see the actual value even after the >> startup. >> Or we should scan pg_wal directory and find the "minimal" WAL segment >> and return its LSN. > > Running a separate scan on pg_wal at startup or first time the oldest > WAL segno is referenced is something that was rejected before. But > with the current behavior we don't find the last removed segment until > any slot loses a segment if all WAL files are retained by a slot. FWIW > I recently proposed a patch to find the oldest WAL file while trying > removing old WAL files.
Hmm. I agree that the approach I previously sent may be kind of confusing without a clear initialization point, which would actually be (checkPointCopy.redo + checkPointCopy.ThisTimeLineID) from the control file with an extra computation depending on any replication slot data present on disk? So one could do the maths cleanly after StartupReplicationSlots() is called in the startup process. My point is: it does not seem really obvious to me that we need to change the control file to track that. > I'm not sure about the consensus here about showing that number in the > view. It is similar to "remain" in the earlier versions of this patch > but a bit simpler. It would be usable in a similar way. I can live > with either numbers. Anyway, here is my take. We are discussing a design issue here, we are moving the discussion into having a different design, and discussing new designs is never a good sign post-beta (some open items tend to move towards this direction every year). So I'd like to think that the best thing we can do here is just to drop min_safe_lsn from pg_replication_slots, and just reconsider this part for 14~ with something we think is better. By the way, I have added a separate open item for this thread. -- Michael
signature.asc
Description: PGP signature
