On Sun, Aug 7, 2022 at 7:07 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Fri, 5 Aug 2022 13:01:19 -0700, Daniel Farina <daniel@fdr.io> wrote in
> > On Fri, Aug 5, 2022 at 12:21 PM David G. Johnston
> > <david.g.johnston@gmail.com> wrote:
> > > On what basis are you considering this a bug? Or, IOW, what do you expect to happen? It doesn't seem possible
forthe promotion to actually happen as the server knows additional WAL must exist that it hasn't yet restored since all
attemptsto restore WAL have succeeded.
> >
> > pg_ctl promote should have consistent behavior regardless of WAL
> > transport. If I (or a computer program of mine) is issuing pg_ctl
> > promote, I mean for it to happen now, that's how it happens with
> > streaming, and in the case of streaming, the amount of WAL that can
> > eventually come into existence is practically unbounded.
>
> pg_ctl just commands or prompts server to do that. The server
> responds to the commands at its convenience. It works the same way
> for start/stop/restart and maybe some other subcommands.
I mean, sure, there's also CHECK_FOR_INTERRUPTS(), so yes, the server
does things at its convenience...but it's a rationale that borders on
the tautological.
Here are some questions:
1) How sure is the present company that this behavior was always the
case, going back to 8.4 or so?
2) What is the recommended method if I am satisfied with the current
recovery progress of a database and wish to promote?
3) Doesn't promote work promptly when the server is streaming? If it
does, why should the behavior be so dramatically different when it is
in archive recovery?