Re: Review for GetWALAvailability()
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-06-25T03:34:16Z
Lists: pgsql-hackers
On 2020/06/25 3:27, Alvaro Herrera wrote: > Thanks for those corrections. > > I have pushed this. I think all problems Masao-san reported have been > dealt with, so we're done here. Sorry for my late to reply here... Thanks for committing the patch and improving the feature! /* * Find the oldest extant segment file. We get 1 until checkpoint removes * the first WAL segment file since startup, which causes the status being * wrong under certain abnormal conditions but that doesn't actually harm. */ oldestSeg = XLogGetLastRemovedSegno() + 1; I see the point of the above comment, but this can cause wal_status to be changed from "lost" to "unreserved" after the server restart. Isn't this really confusing? At least it seems better to document that behavior. Or if we *can ensure* that the slot with invalidated_at set always means "lost" slot, we can judge that wal_status is "lost" without using fragile XLogGetLastRemovedSegno(). Thought? Or XLogGetLastRemovedSegno() should be fixed so that it returns valid value even after the restart? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Commits
-
Persist slot invalidation correctly
- 4ae08cd5fd19 14.0 landed
- 3b4b541777f0 13.0 landed
-
Adjust max_slot_wal_keep_size behavior per review
- b8fd4e02c6d0 14.0 landed
- 6f7a862bed3a 13.0 landed
-
Save slot's restart_lsn when invalidated due to size
- 12e52ba5a76e 13.0 landed
- 0188bb82531f 14.0 landed
-
Fix issues in invalidation of obsolete replication slots.
- 08aa3151e730 13.0 landed
- f9e9704f09da 14.0 landed