# [C] pgpool and -lcompat



## spork (Sep 12, 2013)

I'm not a programmer, but I do understand a tiny bit of C that allows me to do some basic debugging.

For quite some time, recent versions of pgpool build on FreeBSD but spit out some errors on exit regarding the regex filters used to blacklist and whitelist certain SQL functions. As one might expect, that means those particular filters are not being applied, which makes using pgpool in production on FreeBSD a bit dangerous -- these filters are to prevent what might appear to pgpool to be a read-only database operation but is actually a write operation (like nextval()) from being sent to a read-only database slave.

The whole troubleshooting effort I've been going back and forth with the pgpool developer is somewhat complicated, so I won't repeat it here, you can check out the bug report at the pgpool bugtracker.

Right now, the issue seems mostly fixed, but the fix is quite ugly, and what's really bugging me is I don't understand why the fix works. Basically we go through all the Makefiles in the project and remove all references to `-lcompat`. With this change, the regex parser no longer barfs on valid regex patterns and testing seems to indicate the filters are being applied correctly.

So at this point there are three outstanding questions that if answered could get FreeBSD a functioning pgpool port:


What exactly does linking to the compat library do and where is the compat library documented?
Is it proper to fix this by simply not linking to the compat library or is this masking some other underlying problem and/or linuxism in the codebase?
If it is proper to remove the compat library, what's the best crash course for getting familiar enough with autotools to be able to figure out how to stop the `-lcompat` linking?

Any help would be appreciated. If you have good information, feel free to add it directly to the pgpool bugtracker, the developer is stuck at this point.


----------



## ShelLuser (Sep 12, 2013)

spork said:
			
		

> So at this point there are three outstanding questions that if answered could get FreeBSD a functioning pgpool port


Now, maybe I don't understand you correctly but this section gives me the impression that you built pgpool yourself and ran into issues.

But the thing is; there are already a few ports available for pgpool. You have databases/pgpool, databases/pgpool-II and several others. Even databases/pgpoolAdmin is available.

So if something is wrong with those ports I'd definitely start by taking it up with the port maintainer. I can well imagine that he or she could have a better understanding on how to make pgpool fully operational on FreeBSD than the original author.


----------



## spork (Sep 12, 2013)

To confuse the issue, there are a number of pgpools. I'm only looking at the modern ones, which are databases/pgpool-II-*. But even those are quite out of date, most people are running pgpool-3.2 or pgpool-3.1. The latest FreeBSD ports version, databases/pgpool-II-30, is also broken in the same way as what I'm building from source.

As far as I can tell, all of the pgpool ports are currently unmaintained. I've received no responses to my messages to the port maintainer and I've been working on this on and off for quite some time (note the date the bug was opened).

I was actually able to dig up some more information on libcompat tonight, and now I am fairly certain that the way it breaks is via libcompat's alternative regex functions. 'm still curious what libcompat's purpose is and where it's documented, but that's just my own curiosity.

At this point it's a matter of getting autotools to not add the `-lcompat` flag. But that's apparently entering the realm of the dark arts. I'm hoping some FreeBSD folks who deal with building stuff using autotools might have some idea how to accomplish that. Then we can just have the fix upstream and when that's done I can simply submit a port for 3.3.x. I already have a local version that works around all this with some ugly sed-ing of the generated Makefiles.


----------



## spork (Sep 24, 2013)

Just to close this one up, it looks like the developer decided to just remove the `-lcompat` flag from configure.in as a fix of sorts.  That change was committed and should end up in the next release.

So far our testing indicates the blacklist and whitelist functions work correctly.


----------

