[patch] demote
От | Jehan-Guillaume de Rorthais |
---|---|
Тема | [patch] demote |
Дата | |
Msg-id | 20200617174451.222078b4@firost обсуждение исходный текст |
Ответы |
Re: [patch] demote
Re: [patch] demote Re: [patch] demote |
Список | pgsql-hackers |
Hi, As Amul sent a patch about "ALTER SYSTEM READ ONLY"[1], with similar futur objectives than mine, I decided to share the humble patch I am playing with to step down an instance from primary to standby status. I'm still wondering about the coding style, but as the discussion about this kind of feature is rising, I share it in an early stage so it has a chance to be discussed. I'm opening a new discussion to avoid disturbing Amul's one. The design of my patch is similar to the crash recovery code, without resetting the shared memory. It supports smart and fast demote. The only existing user interface currently is "pg_ctl [-m smart|fast] demote". An SQL admin function, eg. pg_demote(), would be easy to add. Main difference with Amul's patch is that all backends must be disconnected to process with the demote. Either we wait for them to disconnect (smart) or we kill them (fast). This makes life much easier from the code point of view, but much more naive as well. Eg. calling "SELECT pg_demote('fast')" as an admin would kill the session, with no options to wait for the action to finish, as we do with pg_promote(). Keeping read only session around could probably be achieved using global barrier as Amul did, but without all the complexity related to WAL writes prohibition. There's still some questions in the current patch. As I wrote, it's an humble patch, a proof of concept, a bit naive. Does it worth discussing it and improving it further or do I miss something obvious in this design that leads to a dead end? Thanks. Regards, [1] https://www.postgresql.org/message-id/flat/CAAJ_b97KZzdJsffwRK7w0XU5HnXkcgKgTR69t8cOZztsyXjkQw%40mail.gmail.com
Вложения
В списке pgsql-hackers по дате отправления: