Re: CHECKPOINT unlogged data
От | Christoph Berg |
---|---|
Тема | Re: CHECKPOINT unlogged data |
Дата | |
Msg-id | aEMVRbmqqg-aaxAN@msg.df7cb.de обсуждение исходный текст |
Ответ на | Re: CHECKPOINT unlogged data (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: CHECKPOINT unlogged data
|
Список | pgsql-hackers |
Re: Nathan Bossart > I imagine the documentation will pretty clearly indicate that setting WAIT > to "false" will cause CHECKPOINT to not wait for it to finish. I can add it, it's easy enough... > I don't understand why we need to add both FAST and IMMEDIATE. We have both: =# checkpoint ; 2025-06-06 18:09:25.743 CEST [872379] LOG: checkpoint starting: immediate force wait pg_basebackup --checkpoint=fast Could we settle for one official name for that? Then we could use that name in all contexts. > > + <term><literal>FLUSH_ALL</literal></term> > > Could we rename this to something like FLUSH_UNLOGGED or INCLUDE_UNLOGGED? > IMHO that's more descriptive. That's again coming from what the log message is saying: =# checkpoint (flush_all); 2025-06-06 18:12:46.298 CEST [873436] LOG: checkpoint starting: immediate force wait flush-all I think we should be consistent there. #define CHECKPOINT_FLUSH_ALL 0x0010 /* Flush all pages, including those * belonging to unlogged tables */ Maybe CHECKPOINT_FLUSH_UNLOGGED would be more explicit? > My attempt at this patch back in 2020 included the following note, which > seems relevant here: > > + Note that the server may consolidate concurrently requested checkpoints or > + restartpoints. Such consolidated requests will contain a combined set of > + options. For example, if one session requested an immediate checkpoint and > + another session requested a non-immediate checkpoint, the server may combine > + these requests and perform one immediate checkpoint. The CHECKPOINT documentation links to `28.5. WAL Configuration`, should this be mentioned there instead? > We might also want to make sure it's clear that CHECKPOINT does nothing if > there's been no database activity since the last one (or, in the case of a > restartpoint, if there hasn't been a checkpoint record). That's taken care of by "force": #define CHECKPOINT_FORCE 0x0008 /* Force even if no activity */ Christoph
В списке pgsql-hackers по дате отправления: