Thread: Re: [COMMITTERS] pgsql: Allow time delayed standbys and recovery
On Tue, Apr 5, 2022 at 8:41 AM Thom Brown <thom@linux.com> wrote: > I know it's been 8 years, but I still think it would be a useful note > to add to the docs. Makes sense. I will do this soon if nobody objects. I'm mildly uncomfortable with the phrase "WAL records generated over the delay period" because it seems a bit imprecise, but I'm not sure what would be better and I think the meaning is clear. Also one of us will need to do s/pg_xlog/pg_wal/. -- Robert Haas EDB: http://www.enterprisedb.com
On Tue, Apr 5, 2022 at 4:54 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Apr 5, 2022 at 8:41 AM Thom Brown <thom@linux.com> wrote:
> I know it's been 8 years, but I still think it would be a useful note
> to add to the docs.
Many points for bringing that one back :)
Makes sense. I will do this soon if nobody objects.
I'm mildly uncomfortable with the phrase "WAL records generated over
the delay period" because it seems a bit imprecise, but I'm not sure
what would be better and I think the meaning is clear.
Maybe "during" instead of "over"? But I'm not sure that's the part you're referring to?
On Tue, Apr 5, 2022 at 10:58 AM Magnus Hagander <magnus@hagander.net> wrote: >> Makes sense. I will do this soon if nobody objects. >> >> I'm mildly uncomfortable with the phrase "WAL records generated over >> the delay period" because it seems a bit imprecise, but I'm not sure >> what would be better and I think the meaning is clear. > > Maybe "during" instead of "over"? But I'm not sure that's the part you're referring to? Yeah, something like that, maybe. -- Robert Haas EDB: http://www.enterprisedb.com
On Tue, 5 Apr 2022 at 16:02, Robert Haas <robertmhaas@gmail.com> wrote: > > On Tue, Apr 5, 2022 at 10:58 AM Magnus Hagander <magnus@hagander.net> wrote: > >> Makes sense. I will do this soon if nobody objects. > >> > >> I'm mildly uncomfortable with the phrase "WAL records generated over > >> the delay period" because it seems a bit imprecise, but I'm not sure > >> what would be better and I think the meaning is clear. > > > > Maybe "during" instead of "over"? But I'm not sure that's the part you're referring to? > > Yeah, something like that, maybe. I share your discomfort with the wording. How about: WAL records must be kept on standby until they are ready to be applied. Therefore, longer delays will result in a greater accumulation of WAL files, increasing disk space requirements for the standby's <filename>pg_wal</> directory. -- Thom
On Wed, 6 Apr 2022 at 01:42, Thom Brown <thom@linux.com> wrote: > > On Tue, 5 Apr 2022 at 16:02, Robert Haas <robertmhaas@gmail.com> wrote: > > > > On Tue, Apr 5, 2022 at 10:58 AM Magnus Hagander <magnus@hagander.net> wrote: > > >> Makes sense. I will do this soon if nobody objects. > > >> > > >> I'm mildly uncomfortable with the phrase "WAL records generated over > > >> the delay period" because it seems a bit imprecise, but I'm not sure > > >> what would be better and I think the meaning is clear. > > > > > > Maybe "during" instead of "over"? But I'm not sure that's the part you're referring to? > > > > Yeah, something like that, maybe. > > I share your discomfort with the wording. How about: > > WAL records must be kept on standby until they are ready to be applied. > Therefore, longer delays will result in a greater accumulation of WAL files, > increasing disk space requirements for the standby's <filename>pg_wal</> > directory. *must be kept on the standby -- Thom
On Tue, Apr 5, 2022 at 8:43 PM Thom Brown <thom@linux.com> wrote: > I share your discomfort with the wording. How about: > > WAL records must be kept on standby until they are ready to be applied. > Therefore, longer delays will result in a greater accumulation of WAL files, > increasing disk space requirements for the standby's <filename>pg_wal</> > directory. Looks awesome. -- Robert Haas EDB: http://www.enterprisedb.com
On Wed, Apr 6, 2022 at 8:15 AM Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Apr 5, 2022 at 8:43 PM Thom Brown <thom@linux.com> wrote: > > I share your discomfort with the wording. How about: > > > > WAL records must be kept on standby until they are ready to be applied. > > Therefore, longer delays will result in a greater accumulation of WAL files, > > increasing disk space requirements for the standby's <filename>pg_wal</> > > directory. > > Looks awesome. Here that is in patch form. I feel that the feature freeze should not preclude committing this documentation improvement, but if someone feels otherwise, then I will leave this until the tree reopens. -- Robert Haas EDB: http://www.enterprisedb.com
Attachment
On Fri, Apr 8, 2022 at 3:36 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Apr 6, 2022 at 8:15 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Apr 5, 2022 at 8:43 PM Thom Brown <thom@linux.com> wrote:
> > I share your discomfort with the wording. How about:
> >
> > WAL records must be kept on standby until they are ready to be applied.
> > Therefore, longer delays will result in a greater accumulation of WAL files,
> > increasing disk space requirements for the standby's <filename>pg_wal</>
> > directory.
>
> Looks awesome.
Here that is in patch form. I feel that the feature freeze should not
preclude committing this documentation improvement, but if someone
feels otherwise, then I will leave this until the tree reopens.
We normally allow documentation and bug fixes after the feature freeze. (It's only in the "we're about to wrap the release right now"-freeze that we have to avoid those)
On Fri, 8 Apr 2022, 14:36 Robert Haas, <robertmhaas@gmail.com> wrote:
On Wed, Apr 6, 2022 at 8:15 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Apr 5, 2022 at 8:43 PM Thom Brown <thom@linux.com> wrote:
> > I share your discomfort with the wording. How about:
> >
> > WAL records must be kept on standby until they are ready to be applied.
> > Therefore, longer delays will result in a greater accumulation of WAL files,
> > increasing disk space requirements for the standby's <filename>pg_wal</>
> > directory.
>
> Looks awesome.
Here that is in patch form. I feel that the feature freeze should not
preclude committing this documentation improvement, but if someone
feels otherwise, then I will leave this until the tree reopens.
Thanks. This doesn't include my self-correction:
s/kept on standby/kept on the standby/
Thom
On Fri, Apr 8, 2022 at 10:45 AM Thom Brown <thom@linux.com> wrote: > Thanks. This doesn't include my self-correction: > > s/kept on standby/kept on the standby/ Here is v2, endeavoring to rectify that oversight. -- Robert Haas EDB: http://www.enterprisedb.com
Attachment
On Fri, Apr 8, 2022 at 11:10 AM Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Apr 8, 2022 at 10:45 AM Thom Brown <thom@linux.com> wrote: > > Thanks. This doesn't include my self-correction: > > > > s/kept on standby/kept on the standby/ > > Here is v2, endeavoring to rectify that oversight. Committed. -- Robert Haas EDB: http://www.enterprisedb.com
On Mon, 11 Apr 2022, 15:55 Robert Haas, <robertmhaas@gmail.com> wrote:
On Fri, Apr 8, 2022 at 11:10 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Apr 8, 2022 at 10:45 AM Thom Brown <thom@linux.com> wrote:
> > Thanks. This doesn't include my self-correction:
> >
> > s/kept on standby/kept on the standby/
>
> Here is v2, endeavoring to rectify that oversight.
Committed.
Much appreciated.
Thom