Re: How can end users know the cause of LR slot sync delays?
| От | Amit Kapila |
|---|---|
| Тема | Re: How can end users know the cause of LR slot sync delays? |
| Дата | |
| Msg-id | CAA4eK1Ls3KfMqyOc-SmFojYRoNGMr7Y0YK_rwrYAHCfm2CqYEA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: How can end users know the cause of LR slot sync delays? (shveta malik <shveta.malik@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Nov 28, 2025 at 3:37 PM Michael Banck <mbanck@gmx.net> wrote: > > Hi, > > On Fri, Nov 28, 2025 at 03:30:48PM +0530, Amit Kapila wrote: > > I suggested the current one because having the last was making the > > column name bit longer, and anyway the description clarifies it, but I > > see your point. So, the other options could be > > slotsync_last_skip_time, sync_last_skip_time, last_slotsync_skip_time, > > last_sync_skip_time . > > I also noticed while going through src/backend/catalog/system_views.sql > that *_last_*_time is rare, so in terms of brevity, removing the _time > at the end would be ok. "last_" already conveys time/a timestamp. > I think it depends on case to case but having last in the similar cases seems to be a common practice. So, again thinking about it based on your suggestion and looking at existing fields, I suggest we should rename slotsync_skip_at to slotsync_last_skip. This is similar to checksum_last_failure. I think there is a value in keeping initials the same for similar fields in the view as users could easily identify the related columns while querying the view. For example, checksum_failures and checksum_last_failure in pg_stat_database. Anyone else have any opinion on the names proposed here? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: