Re: Review for GetWALAvailability()
От | Alvaro Herrera |
---|---|
Тема | Re: Review for GetWALAvailability() |
Дата | |
Msg-id | 20200623230625.GA23391@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Review for GetWALAvailability() (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Review for GetWALAvailability()
|
Список | pgsql-hackers |
On 2020-Jun-16, Kyotaro Horiguchi wrote: > I saw that the "reserved" is the state where slots are working to > retain segments, and "normal" is the state to indicate that "WAL > segments are within max_wal_size", which is orthogonal to the notion > of "reserved". So it seems to me useless when the retained WAL > segments cannot exceeds max_wal_size. > > With longer description they would be: > > "reserved under max_wal_size" > "reserved over max_wal_size" > "lost some segements" > Come to think of that, I realized that my trouble was just the > wording. Are the following wordings make sense to you? > > "reserved" - retained within max_wal_size > "extended" - retained over max_wal_size > "lost" - lost some segments So let's add Unreserved to denote the state that it's over the slot size but no segments have been removed yet: * Reserved under max_wal_size * Extended past max_wal_size, but still within wal_keep_segments or maximum slot size. * Unreserved Past wal_keep_segments and the maximum slot size, but not yet removed. Recoverable condition. * Lost lost segments. Unrecoverable condition. It seems better to me to save the invalidation LSN in the persistent data rather than the in-memory data that's lost on restart. As is, we would lose the status in a restart, which doesn't seem good to me. It's just eight extra bytes to write ... should be pretty much free. This version I propose is based on the one you posted earlier today and is what I propose for commit. Thanks! -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: