Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line - Mailing list pgsql-hackers

From Alexey Kondratov
Subject Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line
Date
Msg-id 13ec67dc-2c6b-777e-902a-1141fdb8302e@postgrespro.ru
Whole thread Raw
In response to Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line
List pgsql-hackers
Hi Dmitry,

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 [1], 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.


[1] 
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2dedf4d9a899b36d1a8ed29be5efbd1b31a8fe85


Regards

-- 
Alexey Kondratov

Postgres Professional https://www.postgrespro.com
Russian Postgres Company


Attachment

pgsql-hackers by date:

Previous
From: Alexander Kuzmenkov
Date:
Subject: Re: Removing unneeded self joins
Next
From: Robert Haas
Date:
Subject: Re: ATTACH/DETACH PARTITION CONCURRENTLY