|From:||Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>|
|To:||Dmitry Dolgov <9erthalion6(at)gmail(dot)com>|
|Cc:||Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, x4mmm(at)yandex-team(dot)ru, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, vladimirlesk(at)yandex-team(dot)ru, dsarafan(at)yandex-team(dot)ru|
|Subject:||Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 30.11.2018 19:04, Dmitry Dolgov wrote:
> Just to confirm, patch still can be applied without conflicts, and pass all the
> tests. Also I like the original motivation for the feature, sounds pretty
> useful. For now I'm moving it to the next CF.
Thanks, although I have slightly updated patch to handle recent merge of
the recovery.conf into GUCs and postgresq.conf , new patch is attached.
>>> - Reusing the GUC parser is something I would avoid as well. Not worth
>>> the complexity.
>> Yes, I don't like it either. I will try to make guc-file.l frontend safe.
> Any success with that?
I looked into it and found that currently guc-file.c is built as part of
guc.c, so it seems to be even more complicated to unbound guc-file.c
from backend. Thus, I have some plan of how to proceed with patch:
1) Add guc-file.h and build guc-file.c separately from guc.c
2) Put guc-file.l / guc-file.h into common/*
3) Isolate all backend specific calls in guc-file.l with #ifdef FRONTEND
Though I am not sure that this work is worth doing against extra
redundancy added by simply adding frontend-safe copy of guc-file.l
lexer. If someone has any thoughts I would be glad to receive comments.
Postgres Professional https://www.postgrespro.com
Russian Postgres Company
|Next Message||Robert Haas||2018-12-24 19:15:42||Re: ATTACH/DETACH PARTITION CONCURRENTLY|
|Previous Message||Alexander Kuzmenkov||2018-12-24 16:28:01||Re: Removing unneeded self joins|