Обсуждение: pg_config problems on PG9.3/Centos?

Ken Tanzer <ken.tanzer@gmail.com> writes:
> When I look the output of pg_config, and especially compared to my 9.2
> output, it seems suspiciously lacking some 9.3 paths:

> [root@new-agency table_log-0.4.4]# pg_config | more
> BINDIR = /usr/bin
> DOCDIR = /usr/share/doc/pgsql
> HTMLDIR = /usr/share/doc/pgsql
> INCLUDEDIR = /usr/include
> PKGINCLUDEDIR = /usr/include
> INCLUDEDIR-SERVER = /usr/include/server
> LIBDIR = /usr/lib
> PKGLIBDIR = /usr/lib
> LOCALEDIR = /usr/share/locale
> MANDIR = /usr/share/man
> SHAREDIR = /usr/share
> SYSCONFDIR = /etc/sysconfig/pgsql

Exactly where is root's path finding pg_config?

IIRC, most of the paths shown here are actually computed relative to the
location of the pg_config executable, so I could imagine getting this
kind of result if you'd done something like symlinking pg_config into
/usr/bin.

I would've guessed that you were invoking a pg_config shipped with the
regular Red Hat postgres packages, except for this:

> CONFIGURE = '--disable-rpath' '--prefix=/usr/pgsql-9.3'
> '--includedir=/usr/pgsql-9.3/include' '--mandir=/
> usr/pgsql-9.3/share/man' '--datadir=/usr/pgsql-9.3/share' '--with-perl'

which seems to prove that the package was built with the correct
options for PGDG's file placement.

            regards, tom lane

Ken Tanzer <ken.tanzer@gmail.com> writes:
> On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> IIRC, most of the paths shown here are actually computed relative to the
>> location of the pg_config executable, so I could imagine getting this
>> kind of result if you'd done something like symlinking pg_config into
>> /usr/bin.

> Oddly, there was a pg_config in /usr/bin that was not a symlink and not
> owned by any package.  I'm really puzzled as to how it got there, but I
> removed it, and symlinked the one from /usr/pgsql-9.3/bin.  It puts out
> better information.

OK.

> It also sounds like from your comment that symlinking to /usr/bin is
> frowned upon.  What is the better way to deal with this?

I had forgotten the details, but if pg_config is giving you the right
answers then it must know about following the symlink.  So nevermind
that worry.

> So with the pg_config thing resolved, my make now get stuck on the error
> below.  I found a BSD bug report with the same message from 9.2, although I
> was able to successfully compile for 9.2 previously.  I'm wondering if
> anyone seems something obvious or simple that could be causing this or
> could be fixed.  I know the table_log packages are kind of ancient, but
> they do the trick!

> table_log.c: In function �table_log�:
> table_log.c:134: warning: implicit declaration of function
> �RelationGetNamespace�
> table_log.c:140: error: dereferencing pointer to incomplete type
> table_log.c: In function �__table_log�:
> table_log.c:301: error: dereferencing pointer to incomplete type
> table_log.c:310: error: dereferencing pointer to incomplete type
> table_log.c:312: error: dereferencing pointer to incomplete type
> table_log.c:346: error: dereferencing pointer to incomplete type
> table_log.c:354: error: dereferencing pointer to incomplete type
> table_log.c:373: error: dereferencing pointer to incomplete type
> table_log.c:381: error: dereferencing pointer to incomplete type
> table_log.c: In function �table_log_restore_table�:
> table_log.c:794: error: �timestamptz_out� undeclared (first use in this
> function)
> table_log.c:794: error: (Each undeclared identifier is reported only once
> table_log.c:794: error: for each function it appears in.)
> make: *** [table_log.o] Error 1

It looks like the code is missing some #include's.  You at least
need utils/rel.h for RelationGetNamespace and utils/timestamp.h
for timestamptz_out.  Can't tell from this what typedef is missing
but it's possible adding those will fix it; if not you'll need to
look at the complained-of lines and then grep the Postgres include
files to see which one provides it.

We occasionally add or remove header inclusions of other headers,
which probably explains why this code compiled on older versions
but not 9.3.

            regards, tom lane

On 01/21/2014 01:18 PM, Ken Tanzer wrote:
> On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us

> Oddly, there was a pg_config in /usr/bin that was not a symlink and not
> owned by any package.  I'm really puzzled as to how it got there, but I
> removed it, and symlinked the one from /usr/pgsql-9.3/bin.  It puts out
> better information.
>
> It also sounds like from your comment that symlinking to /usr/bin is
> frowned upon.  What is the better way to deal with this?
>
> So with the pg_config thing resolved, my make now get stuck on the error
> below.  I found a BSD bug report with the same message from 9.2,
> although I was able to successfully compile for 9.2 previously.  I'm
> wondering if anyone seems something obvious or simple that could be
> causing this or could be fixed.  I know the table_log packages are kind
> of ancient, but they do the trick!
>
> table_log.c: In function ‘table_log’:
> table_log.c:134: warning: implicit declaration of function
> ‘RelationGetNamespace’
> table_log.c:140: error: dereferencing pointer to incomplete type
> table_log.c: In function ‘__table_log’:
> table_log.c:301: error: dereferencing pointer to incomplete type
> table_log.c:310: error: dereferencing pointer to incomplete type
> table_log.c:312: error: dereferencing pointer to incomplete type
> table_log.c:346: error: dereferencing pointer to incomplete type
> table_log.c:354: error: dereferencing pointer to incomplete type
> table_log.c:373: error: dereferencing pointer to incomplete type
> table_log.c:381: error: dereferencing pointer to incomplete type
> table_log.c: In function ‘table_log_restore_table’:
> table_log.c:794: error: ‘timestamptz_out’ undeclared (first use in this
> function)
> table_log.c:794: error: (Each undeclared identifier is reported only once
> table_log.c:794: error: for each function it appears in.)
> make: *** [table_log.o] Error 1
>

I saw a similiar thing on the -odbc list where someone was using PGXS to
build something. It seemed AFAICT the build was not picking up
timestamp.h from the Postgres includes. This is where timestamptz_out is
found. I suggested they manually include it in the *.c file. I never
heard back so I assumed that worked, though I can not be sure.



--
Adrian Klaver
adrian.klaver@gmail.com

Ken Tanzer <ken.tanzer@gmail.com> writes:
> On Tue, Jan 21, 2014 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Ken Tanzer <ken.tanzer@gmail.com> writes:
>>> It also sounds like from your comment that symlinking to /usr/bin is
>>> frowned upon.  What is the better way to deal with this?

>> I had forgotten the details, but if pg_config is giving you the right
>> answers then it must know about following the symlink.  So nevermind
>> that worry.

> I'm happy not to mind, but it seems like everything else just works "out of
> the box," so I wonder why not this little piece?

Nah, it works fine.  I was just jumping to a conclusion based on
insufficient information.

            regards, tom lane

Hi,

On Tue, 2014-01-21 at 13:18 -0800, Ken Tanzer wrote:

> Oddly, there was a pg_config in /usr/bin that was not a symlink and
> not owned by any package.  I'm really puzzled as to how it got there,
> but I removed it, and symlinked the one from /usr/pgsql-9.3/bin.  It
> puts out better information.

Please don't do it. PGDG RPMs are designed for parallel installation
(like 9.2 and 9.3 on the same machine), and then the pg_config in
regular $PATH might be tricky.

Anyway:

> I know the table_log packages are kind of ancient, but they do the
> trick!
>
> table_log.c: In function ‘table_log’:
> table_log.c:134: warning: implicit declaration of function
> ‘RelationGetNamespace’

<snip>

table_log is not being maintained anymore -- you can use emaj. It is
already available in the same RPM repo:

http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/repoview/emaj.html

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

Ken Tanzer <ken.tanzer@gmail.com> writes:
> On Tue, Jan 21, 2014 at 3:16 PM, Devrim G�ND�Z <devrim@gunduz.org> wrote:
>> Please don't do it. PGDG RPMs are designed for parallel installation
>> (like 9.2 and 9.3 on the same machine), and then the pg_config in
>> regular $PATH might be tricky.

> It didn't seem like a great idea to me either, but what's the better
> alternative?  Without the symlink I get lots of errors:

You should arrange for the appropriate pg_config to be in your PATH
when you're using pgxs.  Copying (or symlinking) pg_config into /usr/bin
is a pretty horrible substitute for a temporary PATH change.

            regards, tom lane

Hi,

On Tue, 2014-01-21 at 18:00 -0800, Ken Tanzer wrote:
> It didn't seem like a great idea to me either, but what's the better
> alternative?  Without the symlink I get lots of errors:
>
> make USE_PGXS=1
> make: pg_config: Command not found

Sometimes exporting PG_CONFIG does the trick. Alternatively, while
building the RPMs, we add a patch to makefiles like this:

http://svn.pgrpms.org/repo/rpm/redhat/9.3/ip4r/F-20/Makefile-pgxs.patch

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR