On Fri, 26 Jun 2020 16:14:38 +0900 (JST)
Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
> Hello.
>
> At Thu, 25 Jun 2020 19:27:54 +0200, Jehan-Guillaume de Rorthais
> <jgdr@dalibo.com> wrote in
> > Here is a summary of my work during the last few days on this demote
> > approach.
> >
> > Please, find in attachment v2-0001-Demote-PoC.patch and the comments in the
> > commit message and as FIXME in code.
> >
> > The patch is not finished or bug-free yet, I'm still not very happy with the
> > coding style, it probably lack some more code documentation, but a lot has
> > changed since v1. It's still a PoC to push the discussion a bit further
> > after being myself silent for some days.
> >
> > The patch is currently relying on a demote checkpoint. I understand a forced
> > checkpoint overhead can be massive and cause major wait/downtime. But I keep
> > this for a later step. Maybe we should be able to cancel a running
> > checkpoint? Or leave it to its synching work but discard the result without
> > wirting it to XLog?
>
> If we are going to dive so close to server shutdown, we can just
> utilize the restart-after-crash path, which we can assume to work
> reliably. The attached is a quite rough sketch, hijacking smart
> shutdown path for a convenience, of that but seems working. "pg_ctl
> -m s -W stop" lets server demote.
This was actually my very first toy PoC.
However, resetting everything is far from a graceful demote I was seeking for.
Moreover, such a patch will not be able to evolve to eg. keep read only
backends around.
> > I hadn't time to investigate Robert's concern about shared memory for
> > snapshot during recovery.
>
> The patch does all required clenaup of resources including shared
> memory, I believe. It's enough if we don't need to keep any resources
> alive?
Resetting everything might not be enough. If I understand Robert's concern
correctly, it might actually need more shmem for hot standby xact snapshot. Or
maybe some shmem init'ed differently.
Regards,
