Re: [patch] demote
| От | Jehan-Guillaume de Rorthais |
|---|---|
| Тема | Re: [patch] demote |
| Дата | |
| Msg-id | 20200901112305.55095c50@firost обсуждение исходный текст |
| Ответ на | Re: [patch] demote (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>) |
| Список | pgsql-hackers |
On Tue, 18 Aug 2020 17:41:31 +0200
Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote:
> Hi,
>
> Please find in attachment v5 of the patch set rebased on master after various
> conflicts.
>
> Regards,
>
> On Wed, 5 Aug 2020 00:04:53 +0200
> Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote:
>
> > Demote now keeps backends with no active xid alive. Smart mode keeps all
> > backends: it waits for them to finish their xact and enter read-only. Fast
> > mode terminate backends wit an active xid and keeps all other ones.
> > Backends enters "read-only" using LocalXLogInsertAllowed=0 and flip it to -1
> > (check recovery state) once demoted.
> > During demote, no new session is allowed.
> >
> > As backends with no active xid survive, a new SQL admin function
> > "pg_demote(fast bool, wait bool, wait_seconds int)" had been added.
Just to keep the list inform, I found a race condition leading to backends
trying to write to XLog after they processed the demote signal. Eg.:
[posmaster] LOG: all backends in read only
[checkpointer] LOG: demoting
[backend] PANIC: cannot make new WAL entries during recovery
STATEMENT: UPDATE pgbench_accounts [...]
Because of this Postmaster enters in crash recovery while demote
environnement is in progress.
I have a couple of other subjects right now, but I plan to get back to it soon.
Regards,
В списке pgsql-hackers по дате отправления: