Re: archive status ".ready" files may be created too early
От | Bossart, Nathan |
---|---|
Тема | Re: archive status ".ready" files may be created too early |
Дата | |
Msg-id | EBD2D598-B3B9-4923-A1B8-76A4AEC631B6@amazon.com обсуждение исходный текст |
Ответ на | Re: archive status ".ready" files may be created too early (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: archive status ".ready" files may be created too early
|
Список | pgsql-hackers |
On 7/27/21, 6:05 PM, "Alvaro Herrera" <alvherre@alvh.no-ip.org> wrote: > On 2021-Feb-19, Bossart, Nathan wrote: > >> 0002 adds logic for persisting the last notified segment through >> crashes. This is needed because a poorly-timed crash could otherwise >> cause us to skip marking segments as ready-for-archival altogether. >> This file is only used for primary servers, as there exists a separate >> code path for marking segments as ready-for-archive for standbys. > > I'm not sure I understand what's the reason not to store this value in > pg_control; I feel like I'm missing something. Can you please explain? Thanks for taking a look. The only reason I can think of is that it could make back-patching difficult. I don't mind working on a version of the patch that uses pg_control. Back-patching this fix might be a stretch, anyway. > There were some comments earlier in the thread about the maximum size of > a record. As I recall, you can have records of arbitrary size if you > have COMMIT with a large number of relation invalidation messages being > included in the xlog record, or a large number of XIDs of > subtransactions in the transaction. Spanning several segments is > possible, AFAIU. This is my understanding, too. Nathan
В списке pgsql-hackers по дате отправления: