Re: New option for pg_basebackup, to specify a different directory for pg_xlog

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Haribabu kommi <haribabu(dot)kommi(at)huawei(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New option for pg_basebackup, to specify a different directory for pg_xlog
Date: 2013-12-10 14:24:56
Message-ID: 20131210142455.GO6777@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Haribabu kommi escribió:

> To detect provided data and xlog directories are same or not, I reused the
> Existing make_absolute_path() code as follows.
>
> 1. Moved the make_absolute_path() function from miscinit.c to path.c and
> Changed all error reporting functions. And also it returns NULL incase of
> any error.
>
> 2. Added a new file called fe_path.c which contains make_absolute_path()
> only for frontend code.

Whatever you do, please don't add #include lines to postgres_fe.h. Add
them to whatever .c files that need to include the new header, instead.
(This results in a longer patch, yes, but that consideration shouldn't
drive anything. There is a desire to include as less headers as
possible in each source file, and adding more include lines to
postgres_fe.h means the new header will be included by every single
frontend file, even those not in core.)

See a nearby patch by Bruce Momjian to deal with getpwnam() and
getpwuid() failures; perhaps the idea of returning an error string
should be designed similarly in both these patches. Also consider using
the psprintf stuff, which works on both backend and frontend, avoiding
malloc etc so that code can be shared by both frontend and backend,
eliminating the duplicity.

Thanks,

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2013-12-10 14:31:31 Re: ANALYZE sampling is too good
Previous Message Greg Stark 2013-12-10 14:02:35 Re: ANALYZE sampling is too good