Thread: Re: [PATCH] remove pg_archivecleanup and pg_standby
On 2020-10-29 03:44, Justin Pryzby wrote: > diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml > index 4e833d79ef..be4292ec33 100644 > --- a/doc/src/sgml/contrib.sgml > +++ b/doc/src/sgml/contrib.sgml > @@ -199,6 +199,5 @@ pages. > part of the core <productname>PostgreSQL</productname> distribution. > </para> > > - &pgstandby; > </sect1> > </appendix> With this removal, that section becomes empty. So you probably want to clean up or reorganize this a bit. See https://www.postgresql.org/docs/devel/contrib-prog.html for the context.
On 2020-11-21 20:41, Justin Pryzby wrote: > On Fri, Nov 20, 2020 at 05:26:54PM +0100, Peter Eisentraut wrote: >> On 2020-10-29 03:44, Justin Pryzby wrote: >>> diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml >>> index 4e833d79ef..be4292ec33 100644 >>> --- a/doc/src/sgml/contrib.sgml >>> +++ b/doc/src/sgml/contrib.sgml >>> @@ -199,6 +199,5 @@ pages. >>> part of the core <productname>PostgreSQL</productname> distribution. >>> </para> >>> - &pgstandby; >>> </sect1> >>> </appendix> >> >> With this removal, that section becomes empty. So you probably want to >> clean up or reorganize this a bit. >> >> See https://www.postgresql.org/docs/devel/contrib-prog.html for the context. > > Oops. I guess I'd write something like this. If we just remove it, then > there'd no place to add a new server application, and "client applications" > would be the only subsection. I have committed the typo fix. I don't have a well-formed opinion yet about whether all the reservations about removing pg_standby have been addressed.
On Wed, Nov 25, 2020 at 10:04 PM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > On 2020-11-21 20:41, Justin Pryzby wrote: > > Oops. I guess I'd write something like this. If we just remove it, then > > there'd no place to add a new server application, and "client applications" > > would be the only subsection. > > I have committed the typo fix. I don't have a well-formed opinion yet > about whether all the reservations about removing pg_standby have been > addressed. I would like to commit this, because "waiting restore commands" have confusing interactions with my proposed prefetching-during-recovery patch[1]. Here's a version that fixes an error when building the docs (there was a stray remaining <xref linkend="pgstandby"/>), and adds a commit message. Any objections? Furthermore, I think we should also remove the section of the manual that describes how to write your own "waiting restore command". Thoughts? [1] https://www.postgresql.org/message-id/flat/CA%2BhUKGKFeYPL9K%2BSRixcsx1%2B6HsHhqK%2BPOZyrnnZjw1jERpGcQ%40mail.gmail.com
Attachment
On Wed, Jan 27, 2021 at 04:13:24PM +1300, Thomas Munro wrote: > I would like to commit this, because "waiting restore commands" have > confusing interactions with my proposed prefetching-during-recovery > patch[1]. Here's a version that fixes an error when building the docs > (there was a stray remaining <xref linkend="pgstandby"/>), and adds a > commit message. Any objections? It looks like you are missing two references in your patch set: $ git grep pg_standby doc/src/sgml/high-availability.sgml: Do not use pg_standby or similar tools with the built-in standby mode src/backend/access/transam/xlog.c: * segment. Only recycle normal files, pg_standby for example can create The logic assumed in RemoveXlogFile() is actually a bit scary. I have not checked in details but it could be possible to clean up more code in this area? > Furthermore, I think we should also remove the section of the manual > that describes how to write your own "waiting restore command". > Thoughts? Agreed. No objections to that. -- Michael
Attachment
On Wed, Jan 27, 2021 at 6:06 PM Michael Paquier <michael@paquier.xyz> wrote: > On Wed, Jan 27, 2021 at 04:13:24PM +1300, Thomas Munro wrote: > > I would like to commit this, because "waiting restore commands" have > > confusing interactions with my proposed prefetching-during-recovery > > patch[1]. Here's a version that fixes an error when building the docs > > (there was a stray remaining <xref linkend="pgstandby"/>), and adds a > > commit message. Any objections? > > It looks like you are missing two references in your patch set: > $ git grep pg_standby > doc/src/sgml/high-availability.sgml: Do not use pg_standby or > similar tools with the built-in standby mode > src/backend/access/transam/xlog.c: * segment. Only recycle normal > files, pg_standby for example can create Thanks, fixed. > The logic assumed in RemoveXlogFile() is actually a bit scary. I have > not checked in details but it could be possible to clean up more code > in this area? I think the check that it's a regular file is a good idea anyway, but I removed the offending comment. > > Furthermore, I think we should also remove the section of the manual > > that describes how to write your own "waiting restore command". > > Thoughts? > > Agreed. No objections to that. Thanks!
Attachment
On 2021/01/27 14:32, Thomas Munro wrote: > On Wed, Jan 27, 2021 at 6:06 PM Michael Paquier <michael@paquier.xyz> wrote: >> On Wed, Jan 27, 2021 at 04:13:24PM +1300, Thomas Munro wrote: >>> I would like to commit this, because "waiting restore commands" have >>> confusing interactions with my proposed prefetching-during-recovery >>> patch[1]. Here's a version that fixes an error when building the docs >>> (there was a stray remaining <xref linkend="pgstandby"/>), and adds a >>> commit message. Any objections? I agree with this direction (i.e, remove pg_standby). BTW last month when I gave the talk about possible retire of pg_standbyat PostgreSQL Unconference Tokyo, no one in audience complained about that retire. But one question is; shouldn't we follow "usual" way to retire the feature instead of dropping that immediately? That is,mark pg_standby as obsolete, announce that pg_standby will be dropped after several releases, and then drop pg_standby.This seems safe because there might be some users. While it's been marked as obsolete, maybe WAL prefetch featuredoesn't work with pg_standby, but we can live with that because it's obsolete. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
On Wed, Jan 27, 2021 at 05:08:56PM +0900, Fujii Masao wrote: > But one question is; shouldn't we follow "usual" way to retire the > feature instead of dropping that immediately? That is, mark > pg_standby as obsolete, announce that pg_standby will be dropped > after several releases, and then drop pg_standby. This seems safe > because there might be some users. While it's been marked as > obsolete, maybe WAL prefetch feature doesn't work with pg_standby, > but we can live with that because it's obsolete. Thanks. FWIW, at this stage, my take is just to move on and remove it. If we mark that as obsolete, it will stay around forever while annoying future development. -- Michael
Attachment
On Thu, Jan 28, 2021 at 8:36 PM Michael Paquier <michael@paquier.xyz> wrote: > On Wed, Jan 27, 2021 at 05:08:56PM +0900, Fujii Masao wrote: > > But one question is; shouldn't we follow "usual" way to retire the > > feature instead of dropping that immediately? That is, mark > > pg_standby as obsolete, announce that pg_standby will be dropped > > after several releases, and then drop pg_standby. This seems safe > > because there might be some users. While it's been marked as > > obsolete, maybe WAL prefetch feature doesn't work with pg_standby, > > but we can live with that because it's obsolete. > > Thanks. FWIW, at this stage, my take is just to move on and remove > it. If we mark that as obsolete, it will stay around forever while > annoying future development. I agree. Also, this thing is entirely separate from the server, so a hypothetical user who really wants to upgrade to 14 but keep using pg_standby a bit longer could always use the version that shipped with 13.
On Fri, Jan 29, 2021 at 11:13 AM Thomas Munro <thomas.munro@gmail.com> wrote: > On Thu, Jan 28, 2021 at 8:36 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Wed, Jan 27, 2021 at 05:08:56PM +0900, Fujii Masao wrote: > > > But one question is; shouldn't we follow "usual" way to retire the > > > feature instead of dropping that immediately? That is, mark > > > pg_standby as obsolete, announce that pg_standby will be dropped > > > after several releases, and then drop pg_standby. This seems safe > > > because there might be some users. While it's been marked as > > > obsolete, maybe WAL prefetch feature doesn't work with pg_standby, > > > but we can live with that because it's obsolete. > > > > Thanks. FWIW, at this stage, my take is just to move on and remove > > it. If we mark that as obsolete, it will stay around forever while > > annoying future development. > > I agree. Also, this thing is entirely separate from the server, so a > hypothetical user who really wants to upgrade to 14 but keep using > pg_standby a bit longer could always use the version that shipped with > 13. And, pushed.