Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line
От | Alexey Kondratov |
---|---|
Тема | Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line |
Дата | |
Msg-id | edd2820b-96c8-3bee-0b53-4d933f477f70@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line
|
Список | pgsql-hackers |
On 18.02.2019 19:49, Alvaro Herrera wrote: > >>> On 16.02.2019 6:41, Andres Freund wrote: >>>> It sounds like a seriously bad idea to use a different parser for >>>> pg_rewind. Why don't you just use postgres for it? As in >>>> /path/to/postgres -D /path/to/datadir/ -C shared_buffers >>>> ? > Eh, this is what I suggested in this thread four months ago, though I > didn't remember at the time that aaa6e1def292 had already introduced -C > in 2011. It's definitely the way to go ... all this messing about with > the parser is insane. > Yes, but four months ago recovery options were not a part of GUCs. OK, if you and Andres are surely negative about solution with parser, then I will work out this one with postgres -C and come back till the next commitfest. I found that something similar is already used in pg_ctl and there is a mechanism for finding valid executables in exec.c. So it does not seem to be a big deal at the first sight. Thanks for replies! Regards -- Alexey Kondratov Postgres Professional https://www.postgrespro.com Russian Postgres Company
В списке pgsql-hackers по дате отправления: