Same problem here with version 4.0.7 on Centos . 4.0.6 worked fine

I guess because of header change since 4.0.
Anyways libzbxpgsql.so is a community made module, not a Zabbix official one.

but 4.0.x should not suddenly break the way modules work this has worked fine till 4.0.7

Breaking change: r92127.

but 4.0.x should not suddenly break the way modules work this has worked fine till 4.0.7

I'm sorry to say, but libzbxpgsql has been written in such a way that any minor Zabbix upgrade could have broken it. However, this is a grey area until Zabbix properly documents ZBX-11813.

Here are ZBX discussions around modules compatibility when major version changes.

But breaking it for minor releases is indeed not expected thing.

Same thought here especially as 4 is LTS

I believe this question should be addressed to authors of that module. My guess is that they use internal Zabbix functions that likely changed their definition in 4.0.7. We guarantee compatibility of module API only, definition of our internal functions may change anytime.

then I think that there is urgent need of some good documentation like @Glebs Ivanovskis has mentioned before.

If we can break even in LTS versions with minor updates modules then at the moment Zabbix modules are a no go for me as i have no need in fixing stuff with every small bug fix.

Attached compiled version of libzbxpgsql.so

Compiled on CentOS 7.5.1804 x64
with postgresql-10-devel (from https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm)
with zabbix 4.0.7 source (from https://www.zabbix.com/download_sources#tab:40LTS)

This one works (aka, does not fail to load) with the zabbix 4.0.7 agent.

[Edit: Updated compilation data with OS and library details]

Thx a lot @Herbert Buurman

N.B. the attached binary has debug logging enabled and is very spammy

I'm the author of libzbxpgsql. Issues should be raised here: https://github.com/cavaliercoder/libzbxpgsql/issues

My module definitely imposes some "illegal" dependencies on Zabbix internal/private APIs that are not actually a part of the ABI (E.g. `zbx_snprintf`). Unfortunately, in this case, it finally broke! It's definitely not the fault of the Zabbix devs.

However, some tasks are impossible/difficult/inefficient to reimplement in a module. Examples include writing to log files, compiling JSON objects for discovery rules, fetching Zabbix agent version info, etc. More are captured (and will hopefully be implemented) in ZBXNEXT-3174. In these cases, I made the trade-off and simply used Zabbix private APIs. There is also previous discussion in ZBX-10428

I'm hoping to release a new version of the module eventually that will fix this (and other) issues. Hopefully `i-ky` (God bless you, whoever you are!) has fixed this in https://github.com/cavaliercoder/libzbxpgsql/pull/141. I rarely get time to work on Zabbix projects now

<dimir> i-ky is cyclone

Hi,

Thank you all for keeping an eye out on the issue and providing a workaround. As discussed - since this isn't necessarily a Zabbix bug/issue, I'll be closing the ticket.

If you have any other questions/comments, feel free to reopen it.

Replaced the attached library with a recompiled version that does not cause the inadvertent debuglogging.

MD5sum: d8431130ed5e19bbde12df6839ed8c48

it looks like this patch does the job 

works on 4.0.7 

alexei, is there something module developers can expect in the near future that will make their life easier? Or is the whole idea of binary modules abandoned in favor of embedded Javascript, history export to JSON files and similar stuff?

> Is there something module developers can expect in the near future that will make their life easier?

I am not sure what you are referring to. Please be more specific.

> Or is the whole idea of binary modules abandoned in favor of embedded Javascript, history export to JSON files and similar stuff?

No, it is absolutely not abandoned. Javascript is not a replacement of binary modules in any way! Note that all this functionality (modules, Javascript, external scripts, hooks, etc) is about making Zabbix easier to extend without touching Zabbix code. I would expect this direction will evolve rapidly in the future.

Please be more specific.

I am happy to see some activity in ZBX-15677. I hope that it may eventually lead to ZBXNEXT-2182. Hopefully, ZBXNEXT-5179 will also be resolved. Having ZBXNEXT-4641 would also be helpful. These issues focus on improving and simplifying distribution of modules, making life easier for end users.

Unfortunately there is no activity in ZBXNEXT-2201. And while preprocessing is blooming, it is a pity that modules don't take part in it — ZBXNEXT-2651. Besides preprocessing there are plenty of other applications for loadable modules: ZBXNEXT-2650 and ZBXNEXT-2902 to name a few.

Bugs associated with loadable modules — ZBX-10541, ZBX-11295 — also seem to be long forgotten, even issues as trivial as ZBX-15676 stay unresolved for months.

But the biggest problem is the lack of documentation and the lack of proper examples (ZBX-11811, ZBX-11813). The best thing Zabbix can do in this respect is to write a proper module. I mean something more real-life than dummy module. Something that will need configuration file, logging, synchronization, etc. Create a GitHub repository and try on ryan.armstrong's boots. I'm pretty sure you will quickly realize that there is some fundamental functionality missing... Something like ZBXNEXT-2956 (or at least ZBXNEXT-5189). You will experience that users don't want to compile your module from sources every time they upgrade Zabbix... and stable ABI will be born.

Long ago, around the time loadable modules appeared, a thought of moving existing Zabbix items to modules was entertained. That might help to achieve some of the goals Glebs highlighted. It would also partially help with issues like ZBXNEXT-1085.

libzbxpgsql.so 

compiled the library for 4.4.0

libzbxpgsql.so

4.4.0 version with logging patch from i-ky