From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] remove pg_standby |
Date: | 2021-01-27 03:13:24 |
Message-ID: | CA+hUKGLrL42NSc-yKVvtGVg_=1zq8NFysy-xg1=4DShFsFVB9g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 25, 2020 at 10:04 PM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)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?
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Retire-pg_standby.patch | text/x-patch | 44.7 KB |
v3-0002-Remove-documentation-of-waiting-restore_command.patch | text/x-patch | 6.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-01-27 03:14:33 | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly |
Previous Message | Hou, Zhijie | 2021-01-27 03:12:53 | RE: Parallel INSERT (INTO ... SELECT ...) |