undefined symbol: TupleDescAttr

[herwigg]

Hello, I have compiled informix_fdw on 3.13.0-158-generic #208-Ubuntu SMP Fri Aug 24 17:07:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux from source using the instrucntions in the README During compile/build I get warnings: ifx_fdw.c: In function ‘ifxPrepareParamsForModify’: ifx_fdw.c:1924:5: warning: implicit declaration of function ‘TupleDescAttr’ [-Wimplicit-function-declaration] Form_pg_attribute pgattr = TUPDESC_GET_ATTR(tupdesc, attnum - 1); ^ ifx_fdw.c:150:2: warning: initialization makes pointer from integer without a cast [enabled by default] TupleDescAttr((desc), (index)) ^ ifx_fdw.c:1924:32: note: in expansion of macro ‘TUPDESC_GET_ATTR’ Form_pg_attribute pgattr = TUPDESC_GET_ATTR(tupdesc, attnum - 1); ^ ifx_fdw.c: In function ‘_PG_init’: ifx_fdw.c:5852:2: warning: passing argument 1 of ‘RegisterXactCallback’ from incompatible pointer type [enabled by default] RegisterXactCallback(ifx_fdw_xact_callback, NULL); ^ In file included from ifx_fdw.c:25:0: /pgs001/postgres/9.5AS/include/server/access/xact.h:354:13: note: expected ‘XactCallback’ but argument is of type ‘void ()(enum XactEvent, void )’ extern void RegisterXactCallback(XactCallback callback, void arg); ^ ifx_fdw.c:5853:2: warning: passing argument 1 of ‘RegisterSubXactCallback’ from incompatible pointer type [enabled by default] RegisterSubXactCallback(ifx_fdw_subxact_callback, NULL); ^ In file included from ifx_fdw.c:25:0: /pgs001/postgres/9.5AS/include/server/access/xact.h:358:13: note: expected ‘SubXactCallback’ but argument is of type ‘void ()(enum SubXactEvent, SubTransactionId, SubTransactionId, void )’ extern void RegisterSubXactCallback(SubXactCallback callback, void arg); ^ gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -DLINUX_OOM_ADJ=0 -O2 -DMAP_HUGETLB=0x40000 -fpic -shared -o ifx_fdw.so ifx_connection.o ifx_conncache.o ifx_utils.o ifx_conv.o ifx_fdw.o -L/pgs001/postgres/9.5AS/lib -L/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/lib -L/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/lib -L/opt/local/Current/lib -L/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/lib -Wl,--as-needed -Wl,-rpath,'/pgs001/postgres/9.5AS/lib',--enable-new-dtags -Wl,--no-as-needed -lifsql -lifasf -lifgen -lifos -lifgls -lpthread -lm -ldl -lcrypt /usr/ifx-csdk-current/lib/esql/checkapi.o -lifglx -Wl,--as-needed -L/usr/ifx-csdk-current/lib/ -L/usr/ifx-csdk-current/lib/esql

I ignored these, but at run time I get following error: postgres/9.5AS/lib/ifx_fdw.so: undefined symbol: TupleDescAttr

It is postgres 9.5 enterprise DB Edition. I am not familiar with GITHUB so excuse me if I am not posting in the correct way.

Based on the error I 'suppose' the issue could be resolved by adding an explicit cast to the proper type, but I have no clue what that type should be. Thanks for helping out. Please let me know if you need additional info. Herwig

[laurenz]

This must be caused by d4b4ce203a4d244bb1435c4c8fb4522669a1522f.

It seems like you are building with an old point release of 9.5, older than 9.5.9. The easiest solution is to install a later patch level of PostgreSQL.

Actually, "9.5AS" sounds weird: is that EnterpriseDB's "Advanced Server"? If yes, then you are not dealing with regular PostgreSQL, but a closed source fork, and it is hard to help you there. You'd have to ask EnterpriseDB in that case.

I think that d4b4ce203a4d244bb1435c4c8fb4522669a1522f could be improved, however.

In laurenz/oracle_fdw@798264abea192144fa24a34c9f07c65bbac1764f, did it like this:

#if PG_VERSION_NUM < 110000
/* backport macro from V11 */
#define TupleDescAttr(tupdesc, i) ((tupdesc)->attrs[(i)])
#endif  /* PG_VERSION_NUM */

This works, because the compiler does not complain if you repeat a #define.

[herwigg]

Hi Laurenz,

I applied the fix:

|#if PG_VERSION_NUM < 110000 / backport macro from V11 / #define TupleDescAttr(tupdesc, i) ((tupdesc)->attrs[(i)]) #endif / PG_VERSION_NUM /|

And there were still some compiler warnings, but no errors when using the informix_fdw.

So I suppose it is ok now.

Will you apply this fix on GITHUB ?

Thank you very much.

Herwig

On 9/20/18 6:50 PM, Laurenz Albe wrote:

This must be caused by d4b4ce2 https://github.com/credativ/informix_fdw/commit/d4b4ce203a4d244bb1435c4c8fb4522669a1522f.

It seems like you are building with an old point release of 9.5, older than 9.5.9. The easiest solution is to install a later patch level of PostgreSQL.

Actually, "9.5AS" sounds weird: is that EnterpriseDB's "Advanced Server"? If yes, then you are not dealing with regular PostgreSQL, but a closed source fork, and it is hard to help you there. You'd have to ask EnterpriseDB in that case.

I think that d4b4ce2 https://github.com/credativ/informix_fdw/commit/d4b4ce203a4d244bb1435c4c8fb4522669a1522f could be improved, however.

In laurenz/oracle_fdw@798264a https://github.com/laurenz/oracle_fdw/commit/798264abea192144fa24a34c9f07c65bbac1764f, did it like this:

|#if PG_VERSION_NUM < 110000 / backport macro from V11 / #define TupleDescAttr(tupdesc, i) ((tupdesc)->attrs[(i)]) #endif / PG_VERSION_NUM / |

This works, because the compiler does not complain if you repeat a |#define|.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/credativ/informix_fdw/issues/24#issuecomment-423254948, or mute the thread https://github.com/notifications/unsubscribe-auth/AKO5XhgeaKPeEyms7K423ir4E-pp8nWGks5uc8dzgaJpZM4Wxk-a.

[laurenz]

It's up to @psoo to fix the problem.

I am glad if I could help with the diagnosis.

[psoo]

And there were still some compiler warnings, but no errors when using the informix_fdw.

What kind of other compiler warnings do you see?

[herwigg]

Hello,

Here is the log file of the make command:

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -DLINUX_OOM

_ADJ=0 -O2 -DMAP_HUGETLB=0x40000 -fpic -I/usr/ifx-csdk-current/incl/esql -I. -I./ -I/pgs001/postgres/9.5AS/include/server -I/pgs001/postgres/9.5AS/include/internal -D_GNU_SOURCE -I

/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include/libxml2 -I/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include -I/opt/local/20150616/181474c6-228d-4d58

-b663-17981352ebce/include -I/opt/local/Current/include/libxml2 -I/opt/local/Current/include  -c -o ifx_connection.o ifx_connection.c

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -DLINUX_OOM

_ADJ=0 -O2 -DMAP_HUGETLB=0x40000 -fpic -I/usr/ifx-csdk-current/incl/esql -I. -I./ -I/pgs001/postgres/9.5AS/include/server -I/pgs001/postgres/9.5AS/include/internal -D_GNU_SOURCE -I

/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include/libxml2 -I/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include -I/opt/local/20150616/181474c6-228d-4d58

-b663-17981352ebce/include -I/opt/local/Current/include/libxml2 -I/opt/local/Current/include  -c -o ifx_conncache.o ifx_conncache.c

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -DLINUX_OOM

_ADJ=0 -O2 -DMAP_HUGETLB=0x40000 -fpic -I/usr/ifx-csdk-current/incl/esql -I. -I./ -I/pgs001/postgres/9.5AS/include/server -I/pgs001/postgres/9.5AS/include/internal -D_GNU_SOURCE -I

/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include/libxml2 -I/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include -I/opt/local/20150616/181474c6-228d-4d58

-b663-17981352ebce/include -I/opt/local/Current/include/libxml2 -I/opt/local/Current/include  -c -o ifx_utils.o ifx_utils.c

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -DLINUX_OOM

_ADJ=0 -O2 -DMAP_HUGETLB=0x40000 -fpic -I/usr/ifx-csdk-current/incl/esql -I. -I./ -I/pgs001/postgres/9.5AS/include/server -I/pgs001/postgres/9.5AS/include/internal -D_GNU_SOURCE -I

/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include/libxml2 -I/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include -I/opt/local/20150616/181474c6-228d-4d58

-b663-17981352ebce/include -I/opt/local/Current/include/libxml2 -I/opt/local/Current/include  -c -o ifx_conv.o ifx_conv.c

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -DLINUX_OOM

_ADJ=0 -O2 -DMAP_HUGETLB=0x40000 -fpic -I/usr/ifx-csdk-current/incl/esql -I. -I./ -I/pgs001/postgres/9.5AS/include/server -I/pgs001/postgres/9.5AS/include/internal -D_GNU_SOURCE -I

/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include/libxml2 -I/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/include -I/opt/local/20150616/181474c6-228d-4d58

-b663-17981352ebce/include -I/opt/local/Current/include/libxml2 -I/opt/local/Current/include  -c -o ifx_fdw.o ifx_fdw.c

ifx_fdw.c: In function ‘_PG_init’:

ifx_fdw.c:5857:2: warning: passing argument 1 of ‘RegisterXactCallback’ from incompatible pointer type [enabled by default]

RegisterXactCallback(ifx_fdw_xact_callback, NULL);

  ^

In file included from ifx_fdw.c:25:0:

/pgs001/postgres/9.5AS/include/server/access/xact.h:354:13: note: expected ‘XactCallback’ but argument is of type ‘void ()(enum XactEvent,  void )’

extern void RegisterXactCallback(XactCallback callback, void *arg);

             ^

ifx_fdw.c:5858:2: warning: passing argument 1 of ‘RegisterSubXactCallback’ from incompatible pointer type [enabled by default]

RegisterSubXactCallback(ifx_fdw_subxact_callback, NULL);

  ^

In file included from ifx_fdw.c:25:0:

/pgs001/postgres/9.5AS/include/server/access/xact.h:358:13: note: expected ‘SubXactCallback’ but argument is of type ‘void (*)(enum SubXactEvent,  SubTransactionId,  SubTransaction

Id,  void *)’

extern void RegisterSubXactCallback(SubXactCallback callback, void *arg);

             ^

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -DLINUX_OOM

_ADJ=0 -O2 -DMAP_HUGETLB=0x40000 -fpic -shared -o ifx_fdw.so ifx_connection.o ifx_conncache.o ifx_utils.o ifx_conv.o ifx_fdw.o -L/pgs001/postgres/9.5AS/lib -L/opt/local/20150616/18

1474c6-228d-4d58-b663-17981352ebce/lib -L/opt/local/20150616/181474c6-228d-4d58-b663-17981352ebce/lib -L/opt/local/Current/lib -L/opt/local/20150616/181474c6-228d-4d58-b663-179813

52ebce/lib  -Wl,--as-needed -Wl,-rpath,'/pgs001/postgres/9.5AS/lib',--enable-new-dtags -Wl,--no-as-needed -lifsql -lifasf -lifgen -lifos -lifgls -lpthread -lm -ldl -lcrypt /usr/ifx

-csdk-current/lib/esql/checkapi.o -lifglx -Wl,--as-needed  -L/usr/ifx-csdk-current/lib/ -L/usr/ifx-csdk-current/lib/esql

Op 24/09/2018 om 13:40 schreef Bernd Helmle:

And there were still some compiler warnings, but no errors when
using the informix_fdw.

What kind of other compiler warnings do you see?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/credativ/informix_fdw/issues/24#issuecomment-423946751, or mute the thread https://github.com/notifications/unsubscribe-auth/AKO5XjjLrrQJE05njJvqhdB_AMZ1aCxdks5ueMS_gaJpZM4Wxk-a.

[psoo]

It's up to @psoo to fix the problem.

I am glad if I could help with the diagnosis.

Commit f55232cf35b782672d83a91d3b72b04ef6be5568 makes this mess a little better, i hope.

[psoo]

/pgs001/postgres/9.5AS/include/server/access/xact.h:354:13: note: expected ‘XactCallback’ but argument is of type ‘void ()(enum XactEvent, void )’

The problem with this warning (and the other for RegisterSubXactCallback()) is, that PPAS9.5 has this definition in include/server/access/xact.h:

typedef void (*XactCallback) (XactEvent event, void *arg, bool spl_context);

whereas Vanilla PostgreSQL has this:

typedef void (*XactCallback) (XactEvent event, void *arg);

so one argument less, thus the function pointer declared via this typedef is indeed incompatible with the definitions used in the FDW module. So far, this needs to be adjusted to correctly support EDB PPAS.

Hrm, will see what i can do about this...

[psoo]

Looks like there's no macro i can test for, if we're compiling against PPAS (PG_VERSION_NUM is just the same).

I'm inclined to say we just define an external make macro (like "make USE_EDB=1"), which then picks the right definitions. Anyone compiling against PPAS is then responsible to do the right thing(tm). Not very pretty. And there's still the problem if newer PPAS versions differ in some other ways...

Opinions, Ideas, Anyone?

[laurenz]

You cannot look into PostgresPlus, so you cannot determine if is is safe to ignore the extra parameter.

I don't know, but if I were you, I wouldn't try to adjust for closed source forks and say that it is not officially supported and you are on your own.

[herwigg]

Hello All,

EDB just says: I quote: "Other extensions are developed independently, like PostGIS" end quote.

EDB says there is a FDW for informix but not whether this fdw is compatible with EDB AS Release.

This quote does not say either whether EDB cooperates with you to make an EDB AS compatible informix_fdw extension.

Do you want to make an EDB AS compatible informix_fdw extension ?

Herwig

On 9/26/18 5:09 PM, Bernd Helmle wrote:

Looks like there's no macro i can test for, if we're compiling against PPAS (PG_VERSION_NUM is just the same).

I'm inclined to say we just define an external make macro (like "make USE_EDB=1"), which then picks the right definitions. Anyone compiling against PPAS is then responsible to do the right thing(tm). Not very pretty. And there's still the problem if newer PPAS versions differ in some other ways...

Opinions, Ideas, Anyone?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/credativ/informix_fdw/issues/24#issuecomment-424750761, or mute the thread https://github.com/notifications/unsubscribe-auth/AKO5XjsIrz3v54LUdeT5d-IJP6QxrysCks5ue5iXgaJpZM4Wxk-a.

[psoo]

The problem with these kind of callbacks is (like Laurenz said and I totally agree with him), we cannot have confidence wether the behavior of these are the same or changes with the additonal arguments and its values.

That said, i think the only valid way is to say "no EDB support here". Thats contrary what I want, but without a good way (and documentation) to support those API changes i believe that's the only responsible way.

[herwigg]

Ok,

Thanks very much for your answer, it has the advantage of clarity.

Your remark: "without a good way (and documentation) to support those API changes i believe that's the only responsible way." I suppose from your remark that EDB AS does not offer you documentation or any other insight to support the EDB AS version in your extension.

EDB claims to have an informix_fdw extension but this is in my view an empty statement since the extension is for the community edition of PG and does not apply to the EDB AS edition.

Needless to say I suppose that I regret that you do not have a supported informix fdw version for EDB AS.

But thanks very much for the support.

Herwig

On 9/27/18 10:55 AM, Bernd Helmle wrote:

The problem with these kind of callbacks is (like Laurenz said and I totally agree with him), we cannot have confidence wether the behavior of these are the same or changes with the additonal arguments and its values.

That said, i think the only valid way is to say "no EDB support here". Thats contrary what I want, but without a good way (and documentation) to support those API changes i believe that's the only responsible way.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/credativ/informix_fdw/issues/24#issuecomment-425013211, or mute the thread https://github.com/notifications/unsubscribe-auth/AKO5Xk-rYrpl1MvI0V2_rs1Ihm6uglmLks5ufJKegaJpZM4Wxk-a.

[df7cb]

Detecting PPAS could be achieved by testing one of the following:

#define PACKAGE_NAME "EnterpriseDB"
#define DEF_PGPORT 5444

[psoo]

This might be an option, but doesn't change the issue that i don't know what the 3rd parameter required by the XactCallback functions are doing. Guessing from their name (spl_context), i believe this has to do with the SPL language handler in EDB PPAS. But just guessing is something hard to support...

[psoo]

If Herwig is willing to test (are you?), then i can put a fix into the code and he can test the Informix FDW against his PPAS installation with transactional DML commands...

[herwigg]

Sure,

Just let me know what i can do, next wednesday i can do some tests.

Herwig

Op do 27 sep. 2018 13:28 schreef Bernd Helmle notifications@github.com:

If Herwig is willing to test (are you?), then i can put a fix into the code and he can test the Informix FDW against his PPAS installation with transactional DML commands...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/credativ/informix_fdw/issues/24#issuecomment-425055945, or mute the thread https://github.com/notifications/unsubscribe-auth/AKO5XpBdtrHD5_XFD5l5LwasM9CrXIiaks5ufLZ3gaJpZM4Wxk-a .

[herwigg]

Also , checking on the default listening port 5444

=> not a good idea in my opinion, a lot of companies I have worked for specify a port OTHER than the default port for any number of reasons:

• because they want more than one cluster on the same server

• because they do not want attacks on the (default) port

• because they have rules or a rule system to calculate ports based on enviroment (dev/test/prd), application etcetera.

• because they want to make sure they will never use the same port twice (so that they can put everything on the same machine f they wanted to ) ~ reason 3

Now you can argue about the validity of those rules or the assumptions that were being made when the rules were established but that is not to the point.

Like I said I am willing to test.

Could you please make sure as well to include the fix for the run-time error I got, that was in fact the reason I contacted you in the first place.

Thank you very mich for the effort you put in this case.

Herwig

On 9/27/18 1:28 PM, Bernd Helmle wrote:

If Herwig is willing to test (are you?), then i can put a fix into the code and he can test the Informix FDW against his PPAS installation with transactional DML commands...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/credativ/informix_fdw/issues/24#issuecomment-425055945, or mute the thread https://github.com/notifications/unsubscribe-auth/AKO5XpBdtrHD5_XFD5l5LwasM9CrXIiaks5ufLZ3gaJpZM4Wxk-a.

[df7cb]

The default port is from pg_config.h which you effectively can't edit anyway without recompiling the (closed) EDB sources. This would break for people using vanilla PostgreSQL with ./configure --with-pgport=5444, but who would be doing that...

[psoo]

Please see commit d52ed9f022539eecec3f7b9733ece8f7e079b74e. You can use the USE_EDB_API macro to verify that the Informix FDW works against your PPAS installation (see the commit message for an example on how to pass it via CFLAGS).

Please note that for a correct behavior you need to test DML within transactions and savepoints, as well as nested transactions in SPL procedures. I did some quick testing and it seems to work.

[herwigg]

I just compiled the source code and no more warnings... except for the EDB experimental. Doing some basic sql stuff right now.

[psoo]

Any news on this? If it works for you, i'm going to make a new release and add some documentation.

[herwigg]

it worked fine. But we phased out EDB platform altogether shorly after.