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

From: Haribabu kommi <haribabu(dot)kommi(at)huawei(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, 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-20 09:13:10
Message-ID: 8977CB36860C5843884E0A18D8747B0372BF49AB@szxeml558-mbs.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20 December 2013 02:02 Bruce Momjian wrote:
> On Thu, Dec 19, 2013 at 05:14:50AM +0000, Haribabu kommi wrote:
> > On 19 December 2013 05:31 Bruce Momjian wrote:
> > > On Wed, Dec 11, 2013 at 10:22:32AM +0000, Haribabu kommi wrote:
> > > > The make_absolute_path() function moving to port is changed in
> > > similar
> > > > way as Bruce Momjian approach. The psprintf is used to store the
> > > error
> > > > string which Occurred in the function. But psprintf is not used
> > > > for storing the absolute path As because it is giving problems in
> > > > freeing
> > > the allocated memory in SelectConfigFiles.
> > > > Because the same memory is allocated in a different code branch
> > > > from
> > > guc_malloc.
> > > >
> > > > After adding the make_absolute_path() function with psprintf
> stuff
> > > > in path.c file It is giving linking problem in compilation of
> > > > ecpg. I am
> > > not able to find the problem.
> > > > So I added another file abspath.c in port which contains these
> two
> > > functions.
> > >
> > > What errors are you seeing?
> >
> > If I move the make_absolute_path function from abspath.c to path.c, I
> > was getting following linking errors while compiling "ecpg".
> >
> > ../../../../src/port/libpgport.a(path.o): In function
> `make_absolute_path':
> > /home/hari/postgres/src/port/path.c:795: undefined reference to
> `psprintf'
> > /home/hari/postgres/src/port/path.c:809: undefined reference to
> `psprintf'
> > /home/hari/postgres/src/port/path.c:818: undefined reference to
> `psprintf'
> > /home/hari/postgres/src/port/path.c:830: undefined reference to
> `psprintf'
> > collect2: ld returned 1 exit status
> > make[4]: *** [ecpg] Error 1
> > make[3]: *** [all-preproc-recurse] Error 2
> > make[2]: *** [all-ecpg-recurse] Error 2
> > make[1]: *** [all-interfaces-recurse] Error 2
> > make: *** [all-src-recurse] Error 2
>
> You didn't show the actual command that is generating the error, but I
> assume it is linking ecpg, not creating libecpg. I think the issue is
> that path.c is specially handled when it is included in libecpg. Here
> is a comment from the libecpg Makefile:
>
> # We use some port modules verbatim, but since we need to
> # compile with appropriate options to build a shared lib, we
> can't
> # necessarily use the same object files as the backend uses.
> Instead,
> # symlink the source files in here and build our own object file.
>
> My guess is that libecpg isn't marked as linking to libpgcommon, and
> when you called psprintf in path.c, it added a libpgcommon link
> requirement.
>
> My guess is that if you compiled common/psprintf.c like port/path.c in
> libecpg's Makefile, it would link fine.

Sorry for not mentioning the command, yes it is giving problem while linking ecpg.

From the compilation I observed as libpgcommon is linking while building ecpg.
I tested the same by using psprintf directly in ecpg code.

I modified the libecpg's Makefile as suggested by you which is attached in the mail,
Still the errors are occurring. Please let me know is there anything missed?

Regards,
Hari babu.

Attachment Content-Type Size
make_abs_path_v3.patch application/octet-stream 12.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message MauMau 2013-12-20 11:56:58 Re: [bug fix] pg_ctl always uses the same event source
Previous Message Pavel Stehule 2013-12-20 07:59:41 make_interval ??