On Mon, Nov 18, 2024 at 01:31:45PM +0530, Amit Kapila wrote: > On Mon, Nov 18, 2024 at 12:24 PM Nisha Moond <nisha.moond...@gmail.com> wrote: > > -- inactive_since will be reset to NULL by the process that acquires > > the slot, making it active or in-use again. > > > > AFAIU, inactive_since indicates the point in time when the slot became > > inactive, as the field is set immediately when any of the above > > conditions are triggered. It is not a case where a periodic process > > observes the slot as inactive and sets inactive_since to the "observed > > time", even if the slot was deactivated some time ago. > > > > Given this understanding, and to avoid unnecessary complexity, I agree > > with David's suggestion [1]: > > > > - The time when the slot became inactive. (retained this in patch as > > wording aligns with the field name) > > - The time when the slot was deactivated. > > > > Alternatively, we could use "timestamp" instead of "time" to clearly > > indicate that this refers to a specific timestamp and not a duration: > > "The timestamp indicating when the slot became inactive." > > > > Thoughts? > > > > For the description of synced slots on standby, I’m fine with keeping > > Bruce's suggestion from patch [2] as it is. > > > > Attached the patch with modification. > > > > Looks reasonable to me.
+1 -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?"
